Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL as a local in-memory cache

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: PostgreSQL as a local in-memory cache
Date: 2010-06-17 23:01:29
Message-ID: 4C1AA949.7050301@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-performance
> 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

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2010-06-17 23:17:45
Subject: Re: Add slowdown after conversion to UTF8
Previous:From: Brant FitzsimmonsDate: 2010-06-17 22:28:53
Subject: Add slowdown after conversion to UTF8

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group