Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)
Date: 2022-05-27 21:08:28
Message-ID: 20220527210828.4vsgzz6fhlwzomud@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-05-27 03:30:46 +0200, Tomas Vondra wrote:
> On 5/27/22 02:11, Ranier Vilela wrote:
> > ./pgbench -M prepared -c $conns -j $conns -T 60 -S -n -U postgres
> >
> > pgbench (15beta1)
> > transaction type: <builtin: select only>
> > scaling factor: 1
> > query mode: prepared
> > number of clients: 100
> > number of threads: 100
> > maximum number of tries: 1
> > duration: 60 s
> >
> > conns            tps head              tps patched
> >
> > 1         17126.326108            17792.414234
> > 10       82068.123383            82468.334836
> > 50       73808.731404            74678.839428
> > 80       73290.191713            73116.553986
> > 90       67558.483043            68384.906949
> > 100     65960.982801            66997.793777
> > 200     62216.011998            62870.243385
> > 300     62924.225658            62796.157548
> > 400     62278.099704            63129.555135
> > 500     63257.930870            62188.825044
> > 600     61479.890611            61517.913967
> > 700     61139.354053            61327.898847
> > 800     60833.663791            61517.913967
> > 900     61305.129642            61248.336593
> > 1000   60990.918719            61041.670996
> >
>
> These results look much saner, but IMHO it also does not show any clear
> benefit of the patch. Or are you still claiming there is a benefit?

They don't look all that sane to me - isn't that way lower than one would
expect? Restricting both client and server to the same four cores, a
thermically challenged older laptop I have around I get 150k tps at both 10
and 100 clients.

Either way, I'd not expect to see any GetSnapshotData() scalability effects to
show up on an "Intel® Core™ i5-8250U CPU Quad Core" - there's just not enough
concurrency.

The correct pieces of these changes seem very unlikely to affect
GetSnapshotData() performance meaningfully.

To improve something like GetSnapshotData() you first have to come up with a
workload that shows it being a meaningful part of a profile. Unless it is,
performance differences are going to just be due to various forms of noise.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2022-05-27 21:12:54 Ignore heap rewrites for materialized views in logical replication
Previous Message Thomas Munro 2022-05-27 21:07:31 Re: Bump MIN_WINNT to 0x0600 (Vista) as minimal runtime in 16~