Re: kqueue backend for pgbench

From: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>, Roman Khapov <rkhapov(at)yandex-team(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: kqueue backend for pgbench
Date: 2026-10-28 05:18:38
Message-ID: 1d251dc1-140c-468b-9a45-3918dd3e77ef@postgrespro.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

28.10.2026 08:12, Kirill Reshke wrote:
> On Mon, 26 Oct 2026 at 11:42, Roman Khapov <rkhapov(at)yandex-team(dot)ru> wrote:
>>
>> Hi hackers!
>>
>> While working on [1] I run performance tests on different environments,
>> including laptop with macOS. pgbench is usually chosen for this,
>> but on one of the last runs I discovered that it uses select() on macOS (which lacks
>> the ppoll() syscall), which caps the max amount of clients at 1024 (FD_SETSIZE).
>
> Hi! pgbench with this many clients is an uncommon case, but I can see
> the benefit in stress-testing connection allocation, which in case of
> connection pooler is of interest. So overall +1 for supporting this

We regularly test with couple of thousand clients. But we have to set -j
matching number of -c because otherwise pgbench is bottleneck itself.

Partially it is because of using ppoll, partially because some algorithms
are O(n) on every wakeup in pgbench.

pgbench definitely needs more love.

--
regards
Yura Sokolov aka funny-falcon

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2026-10-28 05:20:25 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Kirill Reshke 2026-10-28 05:12:22 Re: kqueue backend for pgbench