On Wed, Oct 10, 2012 at 2:55 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote:
On Wed, Oct 10, 2012 at 8:27 AM, Seref Arikanyeah. maybe though you might find that the overhead of temp tables is
<serefarikan@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi Merlin,
> Thanks for the response. At the moment, the main function is creating two
> temp tables that drops on commit, and python functions fills these. Not too
> bad, but I'd like to push these temp tables to ram, which is a bit tricky
> due to not having a direct method of doing this with postgresql. (a topic
> that has been discussed in the past in this mail group)
>
> The global variable idea is interesting though. I have not encountered this
> before, is it the global dictionary SD/GD mentioned here:
> http://www.postgresql.org/docs/9.0/static/plpython-sharing.html ?
> It may help perform the expensive transformations once and reuse the
> results.
already pretty good -- they are mostly ram based in typical usage as
they aren't synced. I find actually the greatest overhead in terms of
using them is creation and dropping -- so for very low latency
transactions I use a unlogged permanent table with value returned by
txid_current() as the leading field in the key.
This is very interesting. The reason I've tried to avoid a shared temp
table is that I'd have to have a session id for calls, which led to
severe performance issues with the entity attribute value approach I'm
using in the temp table.
Your approach sounds to have been designed to overcome my problem, but I have no idea what an unlogged table does, and your use of txid_current. Could you explain a bit?
Regards
Seref
Your approach sounds to have been designed to overcome my problem, but I have no idea what an unlogged table does, and your use of txid_current. Could you explain a bit?
Regards
Seref
merlin
