| 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
| 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(). |