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.96) (envelope-from ) id 1w81EP-0008NK-2m for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Apr 2026 19:28:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w81EN-0025wg-1K for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Apr 2026 19:27:59 +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.96) (envelope-from ) id 1w81EN-0025wY-0Q for pgsql-hackers@lists.postgresql.org; Wed, 01 Apr 2026 19:27:59 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w81EK-000000003vD-1y2E for pgsql-hackers@lists.postgresql.org; Wed, 01 Apr 2026 19:27:58 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 631JRsfp3068589; Wed, 1 Apr 2026 15:27:54 -0400 From: Tom Lane To: Andrew Dunstan cc: David Rowley , PostgreSQL Hackers Subject: Re: scale parallel_tuple_cost by tuple width In-reply-to: <2992735.1775066578@sss.pgh.pa.us> References: <2005009.1774880253@sss.pgh.pa.us> <2d7c4e54-6a0b-4b1a-87a6-278c49fa52f0@dunslane.net> <2992735.1775066578@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 01 Apr 2026 14:02:58 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3068587.1775071674.1@sss.pgh.pa.us> Date: Wed, 01 Apr 2026 15:27:54 -0400 Message-ID: <3068588.1775071674@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > macOS/M4-Pro: > Width Parallel(ms) Serial(ms) Speedup Gather rows > ----- ------------ ---------- ------- ----------- > 8 299.464 769.130 2.57x 242549 > 16 310.361 787.629 2.54x 243643 > 32 344.541 839.589 2.44x 242419 > 64 413.330 967.512 2.34x 238771 > 128 519.794 1185.757 2.28x 241440 > 256 1479.766 1823.559 1.23x 238615 > 384 2022.882 2326.823 1.15x 240617 > 512 2423.938 2778.995 1.15x 244752 > 768 3511.425 3934.384 1.12x 235814 > 1024 9905.073 12214.577 1.23x 10000000 On closer review, it looks like I carelessly allowed this test to run in parallel with a buildfarm run. Here are numbers with an idle machine: Width Parallel(ms) Serial(ms) Speedup Gather rows ----- ------------ ---------- ------- ----------- 8 281.881 758.167 2.69x 242549 16 300.997 791.184 2.63x 243643 32 340.815 842.715 2.47x 242419 64 401.282 985.711 2.46x 238771 128 507.066 1183.727 2.33x 241440 256 718.008 1667.830 2.32x 238615 384 1774.601 2224.726 1.25x 240617 512 2439.593 2784.242 1.14x 244752 768 3254.088 3698.615 1.14x 235814 1024 8990.584 12176.341 1.35x 10000000 This is interesting because while the speedup ratio was pretty insensitive to row width on the x86_64 box, that's far from true on the Apple box. regards, tom lane