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 1qV7SM-00GNop-08 for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Aug 2023 09:32:18 +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 1qV7SK-007Yxm-DY for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Aug 2023 09:32:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qV7SK-007Yxe-4Q for pgsql-hackers@lists.postgresql.org; Sun, 13 Aug 2023 09:32:16 +0000 Received: from sfr-1.cri.mines-paristech.fr ([77.158.180.225] helo=smtp.cri.ensmp.fr) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qV7SI-002FBd-EC for pgsql-hackers@lists.postgresql.org; Sun, 13 Aug 2023 09:32:15 +0000 Received: from genua (113x39x105x210.ap113.ftth.ucom.ne.jp [113.39.105.210]) by smtp.cri.ensmp.fr (Postfix) with ESMTPSA id 0C698C00D4 for ; Sun, 13 Aug 2023 11:36:54 +0200 (CEST) Date: Sun, 13 Aug 2023 11:32:08 +0200 (CEST) From: Fabien COELHO Reply-To: Fabien COELHO To: PostgreSQL Developers Subject: pgbench with libevent? Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1381411976-1327593738-1691919133=: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-1327593738-1691919133=:138234 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hello devs, Pgbench is managing clients I/Os manually with select or poll. Much of this could be managed by libevent. Pros: 1. libevent is portable, stable, and widely used (eg Chromium, Memcached, PgBouncer). 2. libevent implements more I/O wait methods, which may be more efficient on some platforms (eg FreeBSD kqueue, Windows wepoll in libevent 2.2 alpha), and hides portability issues. 3. it would remove significant portions of unattractive pgbench code, esp. in threadRun, and around socket/poll abstraction and portability layer. 4. depending on the number of event loops, the client load could be shared more evenly. currently a thread only manages its own clients, some client I/Os may be waiting to be processed while other threads could be available to process them. Cons: 1. it adds a libevent dependency to postgres. This may be a no go from the start. 2. this is a significant refactoring project which implies a new internal architecture and adds new code to process and generate appropriate events. 3. libevent ability to function efficiently in a highly multithreaded environment is unclear. Should there be one event queue which generate a shared work queue? or several event queues, one per thread (which would remove the sharing pro)? or something in between? Some experiments and configuratibility may be desirable. This may also have an impact on pgbench user interface and output depending on the result, eg there may be specialized event and worker threads, some statistics may be slightly different, new options may be needed… 4. libevent development seems slugish, last bugfix was published 3 years ago, version 2.2 has been baking for years, but the development seems lively (+100 contributors). Neutral? 1. BSD 3 clauses license. Is pros > cons, or not? Other thoughts, pros, cons? -- Fabien. --1381411976-1327593738-1691919133=:138234--