From: Josh Berkus <josh@agliodbs.com>
To: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: PostgreSQL as a local in-memory cache
Date: Thu, 17 Jun 2010 16:01:29 -0700
Message-ID: <4C1AA949.7050301@agliodbs.com> (raw)
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>
> Well I guess I'd prefer a per-transaction setting, allowing to bypass
> WAL logging and checkpointing.
Not even conceiveable. For this to work, we're talking about the whole
database installation. This is only a set of settings for a database
*server* which is considered disposable and replaceable, where if it
shuts down unexpectedly, you throw it away and replace it.
> Forcing the backend to care itself for
> writing the data I'm not sure is a good thing, but if you say so.
Oh, yeah, I guess we'd only be turning off the LRU cache operations of
the background writer. Same with checkpoints. Copying between
shared_buffers and the LRU cache would still happen.
> Calling a user function at the end of recovery and before accepting
> connection would be good I think. A user function (per database) is
> better than a script because if you want to run it before accepting
> connections and still cause changes in the database…
Hmmm, you're not quite following my idea. There is no recovery. If the
database shuts down unexpectedly, it's toast and you replace it from
another copy somewhere else.
> (a) and (d) are probably simple, if by "reprovisioning" you mean
> "rm -rf $PGDATA; initdb".
Exactly. Followed by "scp database_image". Or heck, just replacing the
whole VM.
> 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.
Yes, and we'd want to flush dirty pages on an actual shutdown command.
We do want to be able to shut down the DB on purpose.
> Well if the transaction touches a system catalog it better be
> WAL-logged...
Given the above, why?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: josh@agliodbs.com
Subject: Re: PostgreSQL as a local in-memory cache
In-Reply-To: <4C1AA949.7050301@agliodbs.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox