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 1rTDkM-001DIj-Oe for pgsql-performance@arkaria.postgresql.org; Fri, 26 Jan 2024 04:23:22 +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 1rTDkL-008p4e-0a for pgsql-performance@arkaria.postgresql.org; Fri, 26 Jan 2024 04:23:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with utf8esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rTDkK-008p4U-G0 for pgsql-performance@lists.postgresql.org; Fri, 26 Jan 2024 04:23:16 +0000 Received: from facteur.thefreecat.org ([212.129.38.6]) by makus.postgresql.org with utf8esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rTDkA-003PgK-Jx for pgsql-performance@lists.postgresql.org; Fri, 26 Jan 2024 04:23:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thefreecat.org; s=thefreecat; t=1706242979; bh=Brek/6apSgS1PlEcB7LiG7vDxC6AE9kYHiGcDy62EfY=; h=Date:Subject:To:References:From:In-Reply-To; b=D6XgwTgLxWk2AWIBuJSnLNxaamLlK4FuKzm9eBkbX9AT0TUIr7fpo2nIfBVJXTjQx kU1V7Y6kcX/eqVs9EE1tpeXmU05ITnrFRwxJYhaIXLVrT0oCa23U9zkChA/Ap0AaNB OxM+XBcfsf9NWV2vhWJSxlvRNhaj8MTu7C2MdpENcmdHuBngn0ppfSjOAxMeL Original-Subject: Re: I don't understand that EXPLAIN PLAN timings Original-From: Jean-Christophe Boggio Received: from [192.168.1.78] (91-167-190-143.subs.proxad.net [::ffff:91.167.190.143]) (AUTH: LOGIN cat, TLS: TLS1.3,128bits,ECDHE_RSA_AES_128_GCM_SHA256) by facteur.thefreecat.org with ESMTPSA id 0000000009DC06D6.0000000065B333A2.002E2D32; Fri, 26 Jan 2024 05:22:58 +0100 Message-ID: Date: Fri, 26 Jan 2024 05:22:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: I don't understand that EXPLAIN PLAN timings Content-Language: fr-FR, en-US To: pgsql-performance@lists.postgresql.org References: <61e642df-5f48-4e4e-b4c3-58936f90ddaa@thefreecat.org> <7c265c1a-2b87-4dc6-8d83-8c7d98e11a2c@thefreecat.org> <0f1acdd6-1d6a-44bc-80a1-fde4c55c5263@thefreecat.org> <61fab101-c7f1-4a88-8099-5f68bfd4f99d@thefreecat.org> From: Jean-Christophe Boggio In-Reply-To: <61fab101-c7f1-4a88-8099-5f68bfd4f99d@thefreecat.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello, In case it might be useful, I made some more tests. On my dev computer (a notebook) I installed: PostgreSQL 15.5 (Ubuntu 15.5-1.pgdg23.10+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0, 64-bit and PostgreSQL 16.1 (Ubuntu 16.1-1.pgdg23.10+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 13.2.0-4ubuntu3) 13.2.0, 64-bit I adjusted work_mem to 1GB and disabled JIT, restored the same DB, did VACUUM ANALYZE and ran the query several times to lower I/O interference. Execution time is about the same on PG 14, 15 and 16, around ~120ms I noticed that planning time, whatever the version, is very variable between executions (ranging from 0.120ms to 0.400ms), probably due to other programs activity and <1ms measurements imprecision. So the results I gave you in my previous email are probably irrelevant. On our production server, which is running PG 14.10 on Debian 11, same work_mem, execution time is ~45ms but planning time is much more consistent at ~0.110ms Interestingly though, lowering work_mem to 32MB gives 22ms execution time but planning time rises consistently at ~0.7ms On my notebook with work_mem=32MB, execution time is also 22ms but planning time is lower at ~0.4ms (?!?) Let me know if I can do anything to provide you with more useful benchmark. The DB is still very small so it is easy to do tests. JC