Re: pgbench with libevent?

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

In response to

Browse pgsql-hackers by date

  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