[Bizgres-general] [ENG] Re: Statement Queuing take II - Resource Scheduling

[Mark Kirkwood]

> My suggestion will be to not add a counter to the named portal *name* (like
> unnamed_portal_count) at creation time - that will lead to a chain of other
> problems during the following cursor operations, and extra code to get
> around it. One idea would be to add a new field to struct PortalData in
> portal.h that can be your counter/id field. Unnamed portals could be always
> assigned some default number such as 0 or anything that works for you
> keeping in mind that there can only be one unnamed portal at a time. Named
> portals can each have a unique id. It's always possible to iterate through
> all the currently existing portals by poking at the portal hash table. This
> is done for almost each function in portalmem.c, see for example
> AtCommit_Portals().
>
>   
Great - this is pretty much what I was considering!
> If I misunderstood you and you just need a portal *count* you don't even
> need that extra field in portal.h, you can just loop through the hashtable
> at any given time and count how many portals there are at that time...
>
>   

Yeah - I wondered if this might be ok as well, as the increasing number 
idea is possibly faster (i.e not probing the portal hash all the time) 
but means that we'll only be able to have INT_MAX cursors in a 
transaction... (unless I can sort of only probe *sometimes*).

Having said that, for CLOSE and possibly FETCH  I need to get the named 
'cursor' portal... to extract its id anyway... but I guess that is more 
efficient than sequentially reading the portal hash.

Cheers

Mark