To: Dimitri Fontaine <dfontaine@hi-media.com>
cc: Josh Berkus <josh@agliodbs.com>,
	postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: PostgreSQL as a local in-memory cache 
In-reply-to: <m2typ18ow0.fsf@hi-media.com> 
References: <cb0fb58c-9134-4314-a1d0-08fc39f911a6@40g2000pry.googlegroups.com>
	<18287446-8677-46d6-a581-c4777f60ebda@40g2000pry.googlegroups.com>
	<4C1A5B81.8050908@agliodbs.com> <m2typ18ow0.fsf@hi-media.com>
Comments: In-reply-to Dimitri Fontaine <dfontaine@hi-media.com>
	message dated "Thu, 17 Jun 2010 21:01:19 +0200"
Date: Thu, 17 Jun 2010 15:38:30 -0400
Message-ID: <24597.1276803510@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Dimitri Fontaine <dfontaine@hi-media.com> writes:
> Josh Berkus <josh@agliodbs.com> writes:
>> a) Eliminate WAL logging entirely
>> b) Eliminate checkpointing
>> c) Turn off the background writer
>> d) Have PostgreSQL refuse to restart after a crash and instead call an
>> exteral script (for reprovisioning)

> Well I guess I'd prefer a per-transaction setting, allowing to bypass
> WAL logging and checkpointing.

Not going to happen; this is all or nothing.

> Forcing the backend to care itself for
> writing the data I'm not sure is a good thing, but if you say so.

Yeah, I think proposal (c) is likely to be a net loss.

(a) and (d) are probably simple, if by "reprovisioning" you mean
"rm -rf $PGDATA; initdb".  Point (b) will be a bit trickier because
there are various housekeeping activities tied into checkpoints.
I think you can't actually remove checkpoints altogether, just
skip the flush-dirty-pages part.

			regards, tom lane