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