From: Josh Berkus <josh@agliodbs.com>
To: pgsql-performance@postgresql.org
Subject: Re: PostgreSQL as a local in-memory cache
Date: Tue, 15 Jun 2010 16:18:19 -0700
Message-ID: <4C180A3B.7090905@agliodbs.com> (raw)
In-Reply-To: <87ocfcnqmk.fsf@cbbrowne-laptop.afilias-int.info>
References: <cb0fb58c-9134-4314-a1d0-08fc39f911a6@40g2000pry.googlegroups.com>
<87bpbcpabg.fsf@cbbrowne-laptop.afilias-int.info>
<4C17A417.2040600@noao.edu>
<87ocfcnqmk.fsf@cbbrowne-laptop.afilias-int.info>
On 6/15/10 10:37 AM, Chris Browne wrote:
> swampler@noao.edu (Steve Wampler) writes:
>> Or does losing WAL files mandate a new initdb?
>
> Losing WAL would mandate initdb, so I'd think this all fits into the
> set of stuff worth putting onto ramfs/tmpfs. Certainly it'll all be
> significant to the performance focus.
I'd like to see some figures about WAL on RAMfs vs. simply turning off
fsync and full_page_writes. Per Gavin's tests, PostgreSQL is already
close to TokyoCabinet/MongoDB performance just with those turned off; I
wonder if actually having the WAL on a memory partition would make any
real difference in throughput.
I've seen a lot of call for this recently, especially since PostgreSQL
seems to be increasingly in use as a reporting server for Hadoop. Might
be worth experimenting with just making wal writing a no-op. We'd also
want to disable checkpointing, of course.
--
-- 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: <4C180A3B.7090905@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