From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgbench with libevent? |
Date: | 2023-08-14 10:09:52 |
Message-ID: | f526fd90-5cd1-1a33-bbe7-117286499d62@mines-paristech.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Thomas,
>>> Pgbench is managing clients I/Os manually with select or poll. Much of this
>>> could be managed by libevent.
>>
>> Or maybe libuv (used by nodejs?).
>>
>> From preliminary testing libevent seems not too good at fine grain time
>> management which are used for throttling, whereas libuv advertised that it
>> is good at it, although what it does is yet to be seen.
>
> Do you think our WaitEventSet stuff could be good here, if made
> frontend-friendly?
Interesting question.
AFAICS, the answer is that it could indeed probably fit the task, but it
would require significant work to make it thread-compatible, and to
untangle it from IsUnderPosmaster/postmaster death, memory context,
elog/ereport, and other back-end specific stuff.
If you remove all that with a clean abstraction (quite a task), then once
done the question could be why not use libevent/libuv/… in the backend
instead of maintaining more or less the same thing inside postgres?
So ISTM that as far as pgbench is concerned it would be much simpler to
use libevent/libuv/… directly if the pros are enough and the cons not
redhibitory, and provided that the needed detailed features are really
there.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2023-08-14 10:22:24 | Re: pgbench with libevent? |
Previous Message | Amit Kapila | 2023-08-14 10:07:43 | Re: [PATCH] Reuse Workers and Replication Slots during Logical Replication |