From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | thomas(dot)munro(at)gmail(dot)com |
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 10:45:21 |
Message-ID: | 20230814.194521.2280744670701201914.t-ishii@sranhm.sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> It could be refactored to support a different subset of event types --
> maybe just sockets, no latches and obviously no 'postmaster death'.
Ok.
> But figuring out how to make latches work between threads might also
> be interesting for future projects...
Maybe. Some people are working on threading PostgreSQL. They may
already know...
> 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.
Agreed.
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2023-08-14 11:05:21 | Re: [PoC] Improve dead tuple storage for lazy vacuum |
Previous Message | shveta malik | 2023-08-14 10:38:18 | Re: Synchronizing slots from primary to standby |