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

From: Seref Arikan <serefarikan(at)kurumsalteknoloji(dot)com>
To: bret_stern(at)machinemanagement(dot)com
Cc: PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Re: Suggestions for the best strategy to emulate returning multiple sets of results
Date: 2012-10-10 15:11:56
Message-ID: CA+4Thdqyakr2cQY5Dq-VtoqHr7zgiagR3qFjk8F9EZswEpyoPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks Bret,
I'm concerned about what happens when my functions under high load fills
the ramdrive with temporary tables I'm using. The advantage of telling
postgres to use ram with an option to fall back to disk is significantly
better in terms of uptime.
However, I was thinking about some mechanism in the middle tier that
watches the space in the ram drive and redirects queries to functions that
create temp tables on disk, if ram drive is close to full. That may help me
accomplish what I'm trying to

Regards
Seref

On Wed, Oct 10, 2012 at 3:58 PM, Bret Stern <
bret_stern(at)machinemanagement(dot)com> wrote:

> create a ramdrive
> On Wed, 2012-10-10 at 14:27 +0100, Seref Arikan 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.
> >
> > Kind regards
> > Seref
> >
> > On Wed, Oct 10, 2012 at 2:06 PM, Merlin Moncure <mmoncure(at)gmail(dot)com>
> > wrote:
> > On Mon, Oct 8, 2012 at 4:59 PM, Seref Arikan
> > <serefarikan(at)kurumsalteknoloji(dot)com> wrote:
> > > Thanks Merlin,
> > > I've tried arrays but plpython does not support returning
> > arrays of custom
> > > db types (which is what I'd need to do)
> >
> >
> >
> > hm -- yeah. can your custom types be broken down into plain
> > SQL types
> > (that is, composite types?). maybe stash the results in
> > global
> > variable and return it in two calls, or insert into into a
> > tempt
> > table that drops on commit?
> >
> > merlin
> >
>
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Divakar Singh 2012-10-10 15:28:44 Re: libpq-how to add a schema to search path
Previous Message rtshadow 2012-10-10 15:01:49 Re: Compression