Обсуждение: GD global data array capabilities in pltcl

What would be the limitations of using the GD (global data) array in 
pltcl stored procedures ?

I mean, if I'll keep there a big cache for a warehouse using

set GD($itemId,quantity) $computedQuantity
...
then elsewhere

return $GS($itemId,quantity)

would be a problem for let's say , 15000 articles?

How would work the GD array in a heavy multi-user application?
I presume that it is shared among any backend processes, isn't it?

Are there some locking mechanisms?

In other words, is the GD array appropriate to implement some caching 
features for a heavy used application in PostgreSQL?

If not, are there any other sollutions (before going to EJB's and stuff) ?

Thanks in advance,
Constantin Teodorescu
Braila, ROMANIA

On Mon, 14 Oct 2002, Constantin Teodorescu wrote:

> What would be the limitations of using the GD (global data) array in 
> pltcl stored procedures ?
> 
> I mean, if I'll keep there a big cache for a warehouse using
> 
> set GD($itemId,quantity) $computedQuantity
> ...
> then elsewhere
> 
> return $GS($itemId,quantity)
> 
> would be a problem for let's say , 15000 articles?
> 
> How would work the GD array in a heavy multi-user application?
> I presume that it is shared among any backend processes, isn't it?
> 
Comment in the code says:
    /************************************************************     * prefix procedure body with     * upvar #0
<internal_procname>GD
 

so I would say it's not accessable from other functions within the same
backend. I doubt very much that this data is database wide I can only see it
being backend specific.


> Are there some locking mechanisms?
> 
> In other words, is the GD array appropriate to implement some caching 
> features for a heavy used application in PostgreSQL?
> 
> If not, are there any other sollutions (before going to EJB's and stuff) ?
> 
> Thanks in advance,
> Constantin Teodorescu
> Braila, ROMANIA
> 

-- 
Nigel J. Andrews

"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
> so I would say it's not accessable from other functions within the same
> backend. I doubt very much that this data is database wide I can only see it
> being backend specific.

It's definitely backend-local.  I imagine you could access another
procedure's GD if you could determine its name (it's built from the
pg_proc OID, I think).  However, if you want to share global data across
pltcl functions in the same backend session, you shouldn't bother with
GD at all: just create named global Tcl variables.  All pltcl functions
in a backend run in the same interpreter, so they can trivially access
global variables.
        regards, tom lane

Tom Lane wrote:

>"Nigel J. Andrews" <nandrews@investsystems.co.uk> writes:
>  
>
>>so I would say it's not accessable from other functions within the same
>>backend. I doubt very much that this data is database wide I can only see it
>>being backend specific.
>>    
>>
>
>It's definitely backend-local.  I imagine you could access another
>procedure's GD if you could determine its name (it's built from the
>pg_proc OID, I think).  However, if you want to share global data across
>pltcl functions in the same backend session, you shouldn't bother with
>GD at all: just create named global Tcl variables.  All pltcl functions
>in a backend run in the same interpreter, so they can trivially access
>global variables.
>
>  
>

OK. Got that! Thanks a lot!

teo