From: Dimitri Fontaine <dfontaine@hi-media.com>
To: Josh Berkus <josh@agliodbs.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: PostgreSQL as a local in-memory cache
Date: Thu, 17 Jun 2010 21:01:19 +0200
Message-ID: <m2typ18ow0.fsf@hi-media.com> (raw)
In-Reply-To: <4C1A5B81.8050908@agliodbs.com>
References: <cb0fb58c-9134-4314-a1d0-08fc39f911a6@40g2000pry.googlegroups.com>
<18287446-8677-46d6-a581-c4777f60ebda@40g2000pry.googlegroups.com>
<4C1A5B81.8050908@agliodbs.com>
Hi,
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. Forcing the backend to care itself for
writing the data I'm not sure is a good thing, but if you say so.
Then you could have the GUC set for a whole cluster, only a database
etc. We already have synchronous_commit to trade durability against
performances, we could maybe support protect_data = off too.
The d) point I'm not sure still applies if you have per transaction
setting, which I think makes the most sense. The data you choose not to
protect is missing at restart, just add some way to register a hook
there. We already have one (shared_preload_libraries) but it requires
coding in C.
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…
Regards,
--
dim
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: dfontaine@hi-media.com, josh@agliodbs.com
Subject: Re: PostgreSQL as a local in-memory cache
In-Reply-To: <m2typ18ow0.fsf@hi-media.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