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

Jasen,
Thanks for this. My last use of ramdisk was ages ago and I've always had
the idea that it was just a disk in ram with no capability to spill over to
disk.
It appears the mind refuses to acknowledge that this has been the situation
many years ago :)

Some google searches returned others asking the same question, surely
someone must have properly established this under *nix. I'll keep
searching, and post my solution for feedback.

Kind regards
Seref

On Sun, Oct 14, 2012 at 5:54 AM, Jasen Betts <jasen(at)xnet(dot)co(dot)nz> wrote:

> On 2012-10-10, Seref Arikan <serefarikan(at)kurumsalteknoloji(dot)com> wrote:
> > --f46d0443048225e0e704cbb5e0ee
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > 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
>
> That's what operating systems are for, ramdisk is only ever a hint,
> is ram is short it will wind up in swap, if ram is plentiful a disk
> table will be fully buffered in ram.
>
> --
> ⚂⚃ 100% natural
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>