Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qVUWW-000Lc0-LH for pgsql-hackers@arkaria.postgresql.org; Mon, 14 Aug 2023 10:10:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qVUWV-003AZ3-9M for pgsql-hackers@arkaria.postgresql.org; Mon, 14 Aug 2023 10:10:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qVUWU-003AYv-Vg for pgsql-hackers@lists.postgresql.org; Mon, 14 Aug 2023 10:10:07 +0000 Received: from sfr-1.cri.mines-paristech.fr ([77.158.180.225] helo=smtp.cri.ensmp.fr) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qVUWR-0003or-S1 for pgsql-hackers@lists.postgresql.org; Mon, 14 Aug 2023 10:10:05 +0000 Received: from genua (113x39x105x210.ap113.ftth.ucom.ne.jp [113.39.105.210]) by smtp.cri.ensmp.fr (Postfix) with ESMTPSA id 96622C00D4; Mon, 14 Aug 2023 12:14:41 +0200 (CEST) Date: Mon, 14 Aug 2023 12:09:52 +0200 (CEST) From: Fabien COELHO To: Thomas Munro cc: PostgreSQL Developers Subject: Re: pgbench with libevent? In-Reply-To: Message-ID: References: <9633b9f1-c128-7031-6a9e-1af6d247caa0@minesparis.psl.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1381411976-1616057327-1692007799=:138234" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1381411976-1616057327-1692007799=:138234 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hello Thomas, >>> Pgbench is managing clients I/Os manually with select or poll. Much of this >>> could be managed by libevent. >> >> Or maybe libuv (used by nodejs?). >> >> From preliminary testing libevent seems not too good at fine grain time >> management which are used for throttling, whereas libuv advertised that it >> is good at it, although what it does is yet to be seen. > > Do you think our WaitEventSet stuff could be good here, if made > frontend-friendly? Interesting question. AFAICS, the answer is that it could indeed probably fit the task, but it would require significant work to make it thread-compatible, and to untangle it from IsUnderPosmaster/postmaster death, memory context, elog/ereport, and other back-end specific stuff. If you remove all that with a clean abstraction (quite a task), then once done the question could be why not use libevent/libuv/… in the backend instead of maintaining more or less the same thing inside postgres? So ISTM that as far as pgbench is concerned it would be much simpler to use libevent/libuv/… directly if the pros are enough and the cons not redhibitory, and provided that the needed detailed features are really there. -- Fabien. --1381411976-1616057327-1692007799=:138234--