From: | "Nigel J(dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
---|---|
To: | Constantin Teodorescu <teo(at)flex(dot)ro> |
Cc: | PostgreSQL Interfaces <pgsql-interfaces(at)postgresql(dot)org> |
Subject: | Re: GD global data array capabilities in pltcl |
Date: | 2002-10-14 16:20:40 |
Message-ID: | Pine.LNX.4.21.0210141716470.584-100000@ponder.fairway2k.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-10-14 17:28:57 | Re: GD global data array capabilities in pltcl |
Previous Message | Constantin Teodorescu | 2002-10-14 16:12:10 | GD global data array capabilities in pltcl |