[Bizgres-general] Statement Queuing take II - Resource Scheduling (Running with cost and cursors)

[Mark Kirkwood]

Mark Kirkwood wrote:
> Dear all - A progress update:
>
> On Friday Resource Queuing ran for the first time (drum roll)!
>
> In addition, I took the opportunity to implement structure design change 
> discussed in the review, so that the queues are real catalog objects, 
> and also to moved the lock/release into the portal run function itself 
> (PortalRun), as this means it is (theoretically) easy to  push the 
> locking point further down for cursors, so they don't get planned twice.
>
> So all the basic elements are there (some functionally incomplete, but 
> working):
>
> - Queues created in shared memory at system startup.
> - Session initialization determines (and remembers) the queue for the user.
> - Resource Lock taken for appropriate statements.
> - Resource limits checked and updated correctly.
>
>
>   

An update on progress again:

The machinery to  track  limit types other than merely active count was 
running for the first time today, so cost and count limit types are both 
working! (and work_mem could be made to work if I spent time on figuring 
out how to count the possible allocations in a plan).

In addition I was able to fix multiple cursor handling.

The changes boiled down to:

- Assigning an id to the portaldata structure.
- Adding a new hash to track open portals and resource increments for a 
process.
- Amending the proclock structure to have a holders count.
- Amending the proclock structure to have a queue of portal and increments.
- Amending the pgproc structure to have a waiting portal id.

Initially I wanted to use a completely new structure (resproclock) and 
leave proclock alone, but this caused problems - as the various queues 
in lock and pgproc structures expect all entries to be the same size.

Despite the pleasantness of working code, there are some to-think-about 
issues:

1/ I had given resource locks their own lock table in the expectation of 
using the new resproclock structure. So I need to decide whether to try 
to get the proclock/resproclock business working or maybe just merge the 
reslocks back in to the standard locks table (like user locks are), and 
leave proclock with 2 extra attributes.

2/ The maintenance  of the new portal increment hash is a little untidy 
- probably needs to be merged into the various grant and ungrant 
functions (will be doing that the rest of the week).


Cheers

Mark

For the interested the latest wip patch:
http://homepages.paradise.net.nz/markir/download/bizgres/bizgres-resscheduler-08-02.patch