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

From Jim Nasby
Subject Re: What limits Postgres performance when the whole database lives in cache?
Date
Msg-id add13eeb-0947-050c-cca0-53bdc439ceea@BlueTreble.com
Whole thread Raw
In response to Re: What limits Postgres performance when the whole database lives in cache?  (Nicolas Grilly <nicolas@gardentechno.com>)
Responses Re: What limits Postgres performance when the whole database lives in cache?  ("dandl" <david@andl.org>)
List pgsql-general
On 9/8/16 3:15 AM, Nicolas Grilly wrote:
>     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 :-)

My guess is this is a test scenario that completely favors VoltDB while
hamstringing Postgres, such as using no transaction durability at all in
VoltDB while using maximum durability in Postgres. Comparing the cost of
every COMMIT doing an fsync vs not could certainly produce a 25x
difference. There could be other cases where you'd get a 25x difference.

You need to be careful of benchmarks from commercial companies. MySQL
used to tout how fast it was compared to Postgres, using a benchmark it
created specifically for that purpose that had very little to do with
the real world. People eventually discovered that as soon as you had a
concurrent workload Postgres was actually faster.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461


pgsql-general by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Trigger is not working for Inserts from the application
Next
From: Jim Nasby
Date:
Subject: Re: Duplicate data despite unique constraint