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

[Mark Kirkwood]

Jim C. Nasby wrote:
> 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.
>
>
>   
Good point. However, while it might seem like time is being wasted on 
this, I re-raised it as I'm finding that the role-to-limit relationship 
design has significant implications in the backend code - locking and 
startup in particular.

For instance, with the current design having resource information held 
directly in the roles, at startup every role needs to be examined to see 
if it has any resource info. Also in order to be flexible it was 
necessary to use 1 lock for each limit type for each role - so 1 query 
might need to take several locks before it is able to execute (e.g. 1 
for active count, 1 for memory usage total... etc).

Neither of these situations seem ideal, and the new idea of gathering 
the limits into a "resource pool" (let's call it a "resource *queue*" 
from now on...), means that at startup the system only needs to scan the 
the  catalog of resource queues.  Additionally, as the various limits 
are all gathered together into the resource queue, the is only 1 lock 
required before a query can execute. This should improve concurrency, 
and certainly will improve code readability!

So, finally - the feedback from yourself and Josh has been invaluable 
with respect to helping me clarify my own thinking about this area.

Best wishes

Mark


P.s : I'm in the process of doing a mini-review of my progress so far, 
based on an assessment of the code to date. This will cover the above 
point along with some others where I'm still having a little think. I'll 
be posting it to the list soon!