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