Re: What limits Postgres performance when the whole database lives in cache? - Mailing list pgsql-general

From Nicolas Grilly
Subject Re: What limits Postgres performance when the whole database lives in cache?
Date
Msg-id CAG3yVS6fn56pUYO+mFPYKrj2WjU=JHMsMy1f3qk+pbUdHamCpw@mail.gmail.com
Whole thread Raw
In response to Re: What limits Postgres performance when the whole database lives in cache?  ("dandl" <david@andl.org>)
Responses Re: What limits Postgres performance when the whole database lives in cache?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-general
On Thu, Sep 8, 2016 at 2:35 AM, dandl <david@andl.org> wrote:
I understand that. What I'm trying to get a handle on is the magnitude of that cost and how it influences other parts of the product, specifically for Postgres. If the overhead for perfect durability were (say) 10%, few people would care about the cost. But Stonebraker puts the figure at 2500%! His presentation says that a pure relational in-memory store can beat a row store with disk fully cached in memory by 10x to 25x. [Ditto column stores beat row stores by 10x for complex queries in non-updatable data.]

VoltDB replication is synchronous in the same cluster/data center, and asynchronous with a remote cluster/data center. As a consequence, if your application needs to survive a data center power failure with zero data loss, then you have to enable VoltDB's synchronous command logging (which by the way is not available in the Community Edition — only in the Enterprise Edition). When Stonebraker says VoltDB's throughput is 10~25x greater, I'd guess this is with no command logging at all, and no periodic snapshotting.

So my question is not to challenge the Postgres way. It's simply to ask whether there are any known figures that would directly support or refute his claims. Does Postgres really spend 96% of its time in thumb-twiddling once the entire database resides in memory?

Alas, I've been unable to find any relevant benchmark. I'm not motivated enough to install a PostgreSQL and VoltDB and try it for myself :-)

pgsql-general by date:

Previous
From: "Martijn Tonies \(Upscene Productions\)"
Date:
Subject: Re: IDE for function/stored proc development.
Next
From: Gavin Flower
Date:
Subject: Re: IDE for function/stored proc development.