Re: Improving connection scalability: GetSnapshotData()

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improving connection scalability: GetSnapshotData()
Date: 2020-04-06 23:52:28
Message-ID: 20200406235228.lnxcau2wgocnnn22@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-04-06 06:39:59 -0700, Andres Freund wrote:
> > 3) Plain pgbench read-write (you already did it for sure)
>
> -s 100 -M prepared -T 700
>
> autovacuum=off, fsync on:
> clients tps master tps pgxact
> 1 474 479
> 16 4356 4476
> 40 8591 9309
> 198 20045 20261
> 1024 17986 18545
>
> autovacuum=off, fsync off:
> clients tps master tps pgxact
> 1 7828 7719
> 16 49069 50482
> 40 68241 73081
> 198 73464 77801
> 1024 25621 28410
>
> I chose autovacuum off because otherwise the results vary much more
> widely, and autovacuum isn't really needed for the workload.

> These numbers seem pretty decent to me. The regressions seem mostly
> within noise. The one possible exception to that is plain pgbench
> read/write with fsync=off and only a single session. I'll run more
> benchmarks around that tomorrow (but now it's 6am :().

The "one possible exception" turned out to be a "real" regression, but
one that was dead easy to fix: It was an DEBUG1 elog I had left in. The
overhead seems to solely have been the increased code size + overhead of
errstart(). After that there's no difference in the single client case
anymore (I'd not expect a benefit).

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-04-07 00:12:43 Re: [HACKERS] Restricting maximum keep segments by repslots
Previous Message Alvaro Herrera 2020-04-06 23:51:48 Re: [HACKERS] Restricting maximum keep segments by repslots