Re: Suggestions for the best strategy to emulate returning multiple sets of results

Comments inline (sorry, did not cc the group in the other mail)

On Wed, Oct 10, 2012 at 2:55 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

> On Wed, Oct 10, 2012 at 8:27 AM, Seref Arikan
> <serefarikan(at)kurumsalteknoloji(dot)com> 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.
>
> yeah. maybe though you might find that the overhead of temp tables is
> 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

>
> merlin
>