Re: pgbench: option delaying queries till connections establishment?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench: option delaying queries till connections establishment?
Date: 2020-11-16 21:53:51
Message-ID: 20201116215351.svcrqd4mr7kz2wvw@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-11-17 00:09:34 +0300, Marina Polyakova wrote:
> Sorry I'm not familiar with the internal architecture of snapshots, locks
> etc. in postgres, but I wanted to ask - what exact kind of patch for fair
> lwlocks do you want to offer to the community? I applied the 6-th version of
> the patch for fair lwlocks from [1] to the old master branch (see commit
> [2]), started many threads in pgbench (-M prepared -c 1000 -j 500 -T 10 -P1
> -S) and I did not receive stable first progress reports, which IIUC are one
> of the advantages of the discussed patch for the pgbench (see [3])...

Thanks for running some benchmarks.

I think it's quite unsurprising that you'd see skewed numbers initially,
even with fairer locks. Just by virtue of pgbench starting threads and
each thread immediately starting to perform work, you are bound to get
odd pretty meaningless initial numbers. Even without contention, and
when using fewer connections than there are CPUs. And especially when
starting a larger number of connections, because the main pgbench thread
will get fewer and fewer scheduler slices because of the threads running
benchmarks already.

Regards,

Andres

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2020-11-16 22:18:11 Re: VACUUM (DISABLE_PAGE_SKIPPING on)
Previous Message Andres Freund 2020-11-16 21:32:03 Re: pgbench: option delaying queries till connections establishment?