Re: Enabling B-Tree deduplication by default - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Enabling B-Tree deduplication by default
Date
Msg-id CA+TgmoZt_dRESbg4R34G+p2x=s+P51LJbeF6oS=2bTfnatXWXA@mail.gmail.com
Whole thread Raw
In response to Re: Enabling B-Tree deduplication by default  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Enabling B-Tree deduplication by default
List pgsql-hackers
On Thu, Jan 30, 2020 at 1:45 AM Peter Geoghegan <pg@bowt.ie> wrote:
> There is a regression that is just shy of 2% here, as measured in
> insert benchmark "rows/sec" -- this metric goes from "62190.0"
> rows/sec on master to "60986.2 rows/sec" with the patch. I think that
> this is an acceptable price to pay for the benefits -- this is a small
> regression for a particularly unfavorable case. Also, I suspect that
> this result is still quite a bit better than what you'd get with
> either InnoDB or MyRocks on the same hardware (these systems were the
> original targets of the insert benchmark, which was only recently
> ported over to Postgres). At least, Mark Callaghan reports getting
> only about 40k rows/sec inserted in 2017 with roughly comparable
> hardware and test conditions (we're both running with
> synchronous_commit=off, or the equivalent). We're paying a small cost
> in an area where Postgres can afford to take a hit, in order to gain a
> much larger benefit in an area where Postgres is much less
> competitive.

How do things look in a more sympathetic case?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side
Next
From: Peter Eisentraut
Date:
Subject: Re: pgbench - add pseudo-random permutation function