Re: pgbench with libevent?

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
Cc: coelho(at)cri(dot)ensmp(dot)fr, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgbench with libevent?
Date: 2023-08-14 07:15:20
Message-ID: CA+hUKGJRD3p8rc8rf7fXcQqBQmOShEuwAZybpFC08+Rf7Y1nJw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 14, 2023 at 6:07 PM Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2023-08-14 08:01:31 Re: Extract numeric filed in JSONB more effectively
Previous Message Ashutosh Bapat 2023-08-14 07:09:15 Re: Report planning memory in EXPLAIN ANALYZE