Re: pgbench with libevent?
От | Fabien COELHO |
---|---|
Тема | Re: pgbench with libevent? |
Дата | |
Msg-id | eb36f089-98ca-6277-dbae-d8fb7c6ec585@mines-paristech.fr обсуждение исходный текст |
Ответ на | Re: pgbench with libevent? (Thomas Munro <thomas.munro@gmail.com>) |
Список | pgsql-hackers |
>> 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"). Pgbench is really a primitive client on top of libpq. ISTM that completion-based I/O would require to enhance libpq asynchronous-ity, not just expose its underlying fd to allow asynchronous implementations. Currently pgbench only actuall "waits" for results from the server and testing PQisBusy to check whether they are there. > 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". Indeed, libevent has a higher level "buffer" oriented API. > 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. -- Fabien.
В списке pgsql-hackers по дате отправления: