Re: pgbench with libevent? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: pgbench with libevent?
Date
Msg-id CA+hUKGJRD3p8rc8rf7fXcQqBQmOShEuwAZybpFC08+Rf7Y1nJw@mail.gmail.com
Whole thread Raw
In response to Re: pgbench with libevent?  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Responses Re: pgbench with libevent?
Re: pgbench with libevent?
List pgsql-hackers
On Mon, Aug 14, 2023 at 6:07 PM Tatsuo Ishii <ishii@sraoss.co.jp> wrote:
> Interesting. In my understanding this also needs to make Latch
> frontend-friendly?

It could be refactored to support a different subset of event types --
maybe just sockets, no latches and obviously no 'postmaster death'.
But figuring out how to make latches work between threads might also
be interesting for future projects...

Maybe Fabien has completion-based I/O in mind (not just "readiness").
That's something that some of those libraries can do, IIUC.  For
example, when your thread wakes up, it tells you "your socket read is
finished, the data is already in your target buffer".  As opposed to
"you can now call recv() without blocking", so you avoid another trip
into the kernel.  But that's also something we'll eventually want to
figure out in the server.



pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Report planning memory in EXPLAIN ANALYZE
Next
From: Pavel Stehule
Date:
Subject: Re: Extract numeric filed in JSONB more effectively