Thread: 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