Re: kqueue backend for pgbench

From: Roman Khapov <rkhapov(at)yandex-team(dot)ru>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: kqueue backend for pgbench
Date: 2026-10-28 06:40:53
Message-ID: 0821A195-F22A-43CD-8B46-3A7C1F04D72B@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> Tested on my mac, it works.

thanks!

> Didn't look much in code detail here, but the nested stale-fd loop is
> O(nregistered * (num of EV_ERROR)) . Probably fine at pgbench scale.

Yes, the cost is O(nregistered * nclosed), however this is the worst case where all clients
are closed (the test end or the server crash).

The only case I doubt is -C/--connect test. On the other hand
there is sync call of PQconnectdb(), and the kernel usually hands
back the same fd number, in which case EV_ADD just
re-attaches the knote silently, without EV_ERROR.

Ofc this can be fixed with some algo based on sort+merge, but for now I prefer
to keep simple solution; that can be changed later.

In longer term, it might be worth redesigning the way fds are added
and deleted in threadRun loop, in the same spirit as the O(n)-per-wakeup issues
Yura mentioned above.

--
Best regards,
Roman Khapov

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2026-10-28 07:02:05 Re: Fix BRIN numeric_minmax_multi_ops out of range value range merging
Previous Message Michael Paquier 2026-10-28 06:38:55 Re: Return pg_control from pg_backup_stop().