Re: Replication identifiers, take 4

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Steve Singer <steve(at)ssinger(dot)info>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replication identifiers, take 4
Date: 2015-04-10 16:03:05
Message-ID: 20150410160305.GG32335@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-04-07 17:08:16 +0200, Andres Freund wrote:
> I'm starting benchmarks now.

What I'm benchmarking here is the WAL overhead, since that's what we're
debating.

The test setup I used was a pgbench scale 10 instance. I've run with
full_page_write=off to have more reproducible results. This of course
over-emphasizes the overhead a bit. But for a long checkpoint interval
and a memory resident working set it's not that unrealistic.

I ran 50k transactions in a signle b
baseline:
- 20445024
- 20437128
- 20436864
- avg: 20439672
extern 2byte identifiers:
- 23318368
- 23148648
- 23128016
- avg: 23198344
- avg overhead: 13.5%
padding 2byte identifiers:
- 21160408
- 21319720
- 21164280
- avg: 21214802
- avg overhead: 3.8%
extern 4byte identifiers:
- 23514216
- 23540128
- 23523080
- avg: 23525808
- avg overhead: 15.1%

To me that shows pretty clearly that a) reusing the padding is
worthwhile b) even without that using 2byte instead of 4 byte
identifiers is beneficial.

Now. Especially in the case of extern identifiers we *can* optimize a
bit more. But there's no way we can get the efficiency of the version
reusing padding.

To run the benchmarks you need to
SELECT pg_replication_identifier_create('frak');
before starting pgbench with the attached file.

Greetings,

Andres Freund

Attachment Content-Type Size
pgbench.sql text/plain 790 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2015-04-10 19:19:15 Re: TABLESAMPLE patch
Previous Message Bruce Momjian 2015-04-10 15:29:22 Re: basebackups during ALTER DATABASE ... SET TABLESPACE ... not safe?