Re: PostgreSQL as a local in-memory cache - Mailing list pgsql-performance

From jgardner@jonathangardner.net
Subject Re: PostgreSQL as a local in-memory cache
Date
Msg-id 4634b12c-749f-4605-9d95-121b8e2bd9e4@k17g2000pro.googlegroups.com
Whole thread Raw
In response to Re: PostgreSQL as a local in-memory cache  (Chris Browne <cbbrowne@acm.org>)
Responses Re: PostgreSQL as a local in-memory cache  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
Re: PostgreSQL as a local in-memory cache  ("Pierre C" <lists@peufeu.com>)
Re: PostgreSQL as a local in-memory cache  ("Pierre C" <lists@peufeu.com>)
Re: PostgreSQL as a local in-memory cache  (Greg Smith <greg@2ndquadrant.com>)
Re: PostgreSQL as a local in-memory cache  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: PostgreSQL as a local in-memory cache  (Josh Berkus <josh@agliodbs.com>)
List pgsql-performance
On Jun 15, 4:18 pm, j...@agliodbs.com (Josh Berkus) wrote:
> On 6/15/10 10:37 AM, Chris Browne wrote:
>
> 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.
>

My back-of-the-envelope experiment: Inserting single integers into a
table without indexes using a prepared query via psycopg2.

Python Script:
import psycopg2
from time import time
conn = psycopg2.connect(database='jgardner')
cursor = conn.cursor()
cursor.execute("CREATE TABLE test (data int not null)")
conn.commit()
cursor.execute("PREPARE ins AS INSERT INTO test VALUES ($1)")
conn.commit()
start = time()
tx = 0
while time() - start < 1.0:
    cursor.execute("EXECUTE ins(%s)", (tx,));
    conn.commit()
    tx += 1
print tx
cursor.execute("DROP TABLE test");
conn.commit();

Local disk, WAL on same FS:
* Default config => 90
* full_page_writes=off => 90
* synchronous_commit=off => 4,500
* fsync=off => 5,100
* fsync=off and synchronous_commit=off => 5,500
* fsync=off and full_page_writes=off => 5,150
* fsync=off, synchronous_commit=off and full_page_writes=off => 5,500

tmpfs, WAL on same tmpfs:
* Default config: 5,200
* full_page_writes=off => 5,200
* fsync=off => 5,250
* synchronous_commit=off => 5,200
* fsync=off and synchronous_commit=off => 5,450
* fsync=off and full_page_writes=off => 5,250
* fsync=off, synchronous_commit=off and full_page_writes=off => 5,500

NOTE: If I do one giant commit instead of lots of littler ones, I get
much better speeds for the slower cases, but I never exceed 5,500
which appears to be some kind of wall I can't break through.

If there's anything else I should tinker with, I'm all ears.


pgsql-performance by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Analysis Function
Next
From: Mark Kirkwood
Date:
Subject: Re: PostgreSQL as a local in-memory cache