Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Josh Berkus" <josh@agliodbs.com>, "postgres performance list"
	<pgsql-performance@postgresql.org>
Subject: Re: PostgreSQL as a local in-memory cache
References: <cb0fb58c-9134-4314-a1d0-08fc39f911a6@40g2000pry.googlegroups.com>
	<18287446-8677-46d6-a581-c4777f60ebda@40g2000pry.googlegroups.com>
	<4C1A5B81.8050908@agliodbs.com>
Date: Thu, 17 Jun 2010 20:44:04 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Pierre C" <lists@peufeu.com>
Message-ID: <op.vegjnqfreorkce@apollo13>
In-Reply-To: <4C1A5B81.8050908@agliodbs.com>
User-Agent: Opera Mail/10.10 (Linux)


> Especially as, in repeated tests, PostgreSQL with persistence turned off  
> is just as fast as the fastest nondurable NoSQL database.  And it has a  
> LOT more features.

An option to completely disable WAL for such use cases would make it a lot  
faster, especially in the case of heavy concurrent writes.

> Now, while fsync=off and tmpfs for WAL more-or-less eliminate the IO for  
> durability, they don't eliminate the CPU time.

Actually the WAL overhead is some CPU and lots of locking.

> Which means that a caching version of PostgreSQL could be even faster.    
> To do that, we'd need to:
>
> 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)
>
> Of the three above, (a) is the most difficult codewise.

Actually, it's pretty easy, look in xlog.c