Re: PostgreSQL on RAM Disk / tmpfs - Mailing list pgsql-general

From Merlin Moncure
Subject Re: PostgreSQL on RAM Disk / tmpfs
Date
Msg-id b42b73150608081654s4112f202q353686b412f950b7@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL on RAM Disk / tmpfs  ("Thomas F. O'Connell" <tfo@sitening.com>)
List pgsql-general
On 8/8/06, Thomas F. O'Connell <tfo@sitening.com> wrote:
>
> On Aug 8, 2006, at 1:10 PM, Merlin Moncure wrote:
>
> > On 8/8/06, Thomas F. O'Connell <tfo@sitening.com> wrote:
> >> On Aug 3, 2006, at 1:26 PM, Merlin Moncure wrote:
> >> > if have super high write volumes, consider writing your insert
> >> call in
> >> > C. prepare your statement, and use the parameterized
> >> > version....ExecPrepared(...).
> >>
> >> Can you point to a good example of this anywhere in the docs? I don't
> >> see ExecPrepared anywhere in the core documentation.
> >
> > well, it's actually PQexecPrepared()
> > http://www.postgresql.org/docs/8.1/interactive/libpq-exec.html
> >
> > do some tests and you should see a nice improvement over PQexec().
>
> Thanks!
>
> I remain curious, though: in the event that a RAM-disk-based
> architecture remains in place, do all traditional disk-based
> considerations go out the window? For instance, does trying to

if you are not syncing, the computer essentially is a giant ram disk.
the operating system just pages ram to disk here and there to free up
more ram for temporary demands.  while kernel buffers are slower than
local process memory, they are still awfully fast compared to disk
drives.  operating systems thes days are pretty good about deciding
what should and should not stay in ram, better than most people
believe.  it's *usually* a rookie sysadmin move to force things into
memory this way.  another common sysadmin misadventure is to turn off
the o/s swap file.

> cluster same-table statements together in a transaction in an effort
> to reduce disk activity make any difference?

there is still a small savings due to optimizng transaction cleanup
although you have to handle failures which can be a downside.

> And is the overall strategy of attempting to keep distance between
> checkpoints somewhat high (especially since the need for
> checkpointing overall is reduced) still a good basis?

depends. with fsync=off, usually the  only time you are worried about
checkpoints is during bullk load, and i think in these cases you will
want to increase wal segments and leave the bgwriter alone.

merlin

pgsql-general by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Practical maximums (was Re: PostgreSQL theoretical
Next
From: "Jaime Casanova"
Date:
Subject: Re: Dumping database using 8.1 or 7.1