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
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 |