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

From Merlin Moncure
Subject Re: PostgreSQL on RAM Disk / tmpfs
Date
Msg-id b42b73150608031126h1b990f60t8070b170a42748cd@mail.gmail.com
Whole thread Raw
In response to PostgreSQL on RAM Disk / tmpfs  ("Thomas F. O'Connell" <tfo@sitening.com>)
Responses Re: PostgreSQL on RAM Disk / tmpfs  ("Thomas F. O'Connell" <tfo@sitening.com>)
List pgsql-general
On 8/2/06, Thomas F. O'Connell <tfo@sitening.com> wrote:
> I'm working on a postgres instance (8.1.2 running on Solaris 10) where the
> data directory (including WAL) is being mounted on tmpfs. Based on this, and
> with knowledge that fsync is disabled, I'm operating under the assumption
> that recoverability is not a precondition for optimized performance. With
> that assumption, I have several questions, some performance-related, others
> internals-related:

to be honest, I think the best approach is to simply write to the
traditional filesystem and leave fsync off.  writing to a ramdisk
might be a bit faster, but you deprive the server memory from doing
other things like caching and sorting.  this might be more true for
some o/s than others though.  i'm just curious, what led you to do
ramdisk implementation  (most people who ask questions about ramdisk
have no idea what they are talking about, although you seem to).

> 4. Considering that recoverability is not a precondition, is there an easy
> patch that could be applied to the 8.1.x series from 8.1.4 on that would
> allow disabling full_page_writes? For a database in RAM with high write
> volume, is this setting even likely to make a difference?

I would suggest pulling 8.2dev (shortly beta) if you want this and
experiment. it is perfectly stable.  looking at the todo list, 8.2
also gets the multiple insert syntax, which is nice.

if have super high write volumes, consider writing your insert call in
C. prepare your statement, and use the parameterized
version....ExecPrepared(...).

merlin

pgsql-general by date:

Previous
From: Jim Nasby
Date:
Subject: PITR timeline question
Next
From: Rafal Pietrak
Date:
Subject: Re: CREATE DATABASE