pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedGD global data array capabilities in pltcl
4+ messages / 3 participants
[nested] [flat]
* GD global data array capabilities in pltcl
@ 2002-10-14 16:12 Constantin Teodorescu <teo@flex.ro>
2002-10-14 16:20 ` Re: GD global data array capabilities in pltcl Nigel J. Andrews <nandrews@investsystems.co.uk>
0 siblings, 1 reply; 4+ messages in thread
From: Constantin Teodorescu @ 2002-10-14 16:12 UTC (permalink / raw)
To: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: GD global data array capabilities in pltcl
2002-10-14 16:12 GD global data array capabilities in pltcl Constantin Teodorescu <teo@flex.ro>
@ 2002-10-14 16:20 ` Nigel J. Andrews <nandrews@investsystems.co.uk>
2002-10-14 17:28 ` Re: GD global data array capabilities in pltcl Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 4+ messages in thread
From: Nigel J. Andrews @ 2002-10-14 16:20 UTC (permalink / raw)
To: Constantin Teodorescu <teo@flex.ro>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: GD global data array capabilities in pltcl
2002-10-14 16:12 GD global data array capabilities in pltcl Constantin Teodorescu <teo@flex.ro>
2002-10-14 16:20 ` Re: GD global data array capabilities in pltcl Nigel J. Andrews <nandrews@investsystems.co.uk>
@ 2002-10-14 17:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2002-10-15 05:26 ` Re: GD global data array capabilities in pltcl Constantin Teodorescu <teo@flex.ro>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2002-10-14 17:28 UTC (permalink / raw)
To: Nigel J. Andrews <nandrews@investsystems.co.uk>; +Cc: Constantin Teodorescu <teo@flex.ro>; pgsql-interfaces
"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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: GD global data array capabilities in pltcl
2002-10-14 16:12 GD global data array capabilities in pltcl Constantin Teodorescu <teo@flex.ro>
2002-10-14 16:20 ` Re: GD global data array capabilities in pltcl Nigel J. Andrews <nandrews@investsystems.co.uk>
2002-10-14 17:28 ` Re: GD global data array capabilities in pltcl Tom Lane <tgl@sss.pgh.pa.us>
@ 2002-10-15 05:26 ` Constantin Teodorescu <teo@flex.ro>
0 siblings, 0 replies; 4+ messages in thread
From: Constantin Teodorescu @ 2002-10-15 05:26 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nigel J. Andrews <nandrews@investsystems.co.uk>; pgsql-interfaces
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
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2002-10-15 05:26 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2002-10-14 16:12 GD global data array capabilities in pltcl Constantin Teodorescu <teo@flex.ro>
2002-10-14 16:20 ` Nigel J. Andrews <nandrews@investsystems.co.uk>
2002-10-14 17:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2002-10-15 05:26 ` Constantin Teodorescu <teo@flex.ro>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox