[Bizgres-general] Statement Queuing take II - Resource Scheduling

[Jim C. Nasby]

I don't think it'd be hard to come up with use cases for every idea
that's been presented thus far, but right now there's just no way to
know what's realistic and what isn't.

My take is that this is such a new concept that it's impossible for us
to forsee how it's going to be used at this point. Because of that, I
think we should KISS right now and make sure we don't limit our options
in the future. I'd say limiting this to only the login role and having
to manually set all the limits is fine as a starting point. There's
plenty of other stuff to worry about; if we get bogged down in designing
the user interface to this it'll never get off the ground.

On Fri, Jun 30, 2006 at 06:55:56PM +1200, Mark Kirkwood wrote:
> Josh Berkus wrote:
> > Jim,
> >
> >   
> >> I'm thinking that for the first pass maybe we should only look at
> >> whatever role you have active at the time. 
> >>     
> >
> > Yes.  By "lowest role in the tree" I meant "partents of the role currently 
> > active".  As in, do not try to do anything fancy with recursive analysis of 
> > the parent roles.
> >
> > Hmm.  I can see some problems with that too.  How are parameters set for 
> > parent roles (like SEARCH_PATH) currently handled?
> >
> >   
> 
> Looks to me like login role overrides role settings in that case (i.e 
> user A does SET ROLE b - but search_path stays at what user A has 
> configured).
> 
> Also, I'm thinking that having to set limit parameters individually for 
> each (login) role is painful - plus it becomes hard to know what your 
> effective management limits actually are. 
> 
> A possibility is to create a new object (say) "resource pool", and 
> attach the limits to *them*, and roles can specify one resource pool - 
> and only the current role's resource pool is *ever* used by the 
> scheduler code.
> 
> This means instead of having to specify limits for each (login) role (at 
> least), you can have a few resource pools and specify one of them for 
> each role . This gets us back to a sane amount of management, plus 
> reasonable flexibility. A new catalog object ("resource pool" or 
> something) is then required.
> 
> >> Or, take the minimum of all 
> >> limits that apply to roles that are directly INHERITed by the current
> >> role, if SET ROLE hasn't been used.
> >>     
> >
> > No.  Too complicated, for no real benefit.
> >
> >   
> Yeah - I'm thinking that too.
> >> Right - The SET ROLE is a bit alarming, as it means users can 'switch
> >> off' their resource limits in some cases. 
> >>     
> >
> > I see this as a feature and not a flaw.  Think of the smart DBA who wants to 
> > deliberately run some queries as "joe user" and others as "report writer".  
> > He can SET ROLE, run some queries, SET ROLE again, and run the others.
> >
> > It does mean that you have to be careful what roles your users belong to, but 
> > when is that not the case?
> >
> >   
> Yeah, agreed.
> 
> Cheers
> 
> Mark
> _______________________________________________
> Bizgres-general mailing list
> Bizgres-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/bizgres-general
> 

-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby at pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461