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 1ruYSU-0065nX-Pr for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Apr 2024 13:57:51 +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 1ruYST-002z5A-W9 for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Apr 2024 13:57:49 +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 1ruYST-002z4M-Lx for pgsql-hackers@lists.postgresql.org; Wed, 10 Apr 2024 13:57:49 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ruYSO-000Ce2-LH for pgsql-hackers@postgresql.org; Wed, 10 Apr 2024 13:57:49 +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 43ADvZev4017528; Wed, 10 Apr 2024 09:57:35 -0400 From: Tom Lane To: Matthias van de Meent cc: stepan rutz , Tomas Vondra , pgsql-hackers@postgresql.org Subject: Re: Detoasting optionally to make Explain-Analyze less misleading In-reply-to: References: <2802772.1694532399@sss.pgh.pa.us> <03f952d6-b773-be93-e5d5-8f9ea9c2d461@gmx.de> <7b7d46b1-d6f7-eb10-55c9-aa45fce57781@enterprisedb.com> <9126b7da-204b-4701-8e2b-37fb824a0cf4@gmx.de> <78507aa1-f850-50cd-458a-3986d973d092@enterprisedb.com> <886b209f-8736-9cf2-ab9c-89870dea7bd8@enterprisedb.com> <14746b40-16a8-b53e-18a6-f2872e696e34@enterprisedb.com> <1642956.1712072848@sss.pgh.pa.us> <384054.1712181051@sss.pgh.pa.us> Comments: In-reply-to Matthias van de Meent message dated "Wed, 10 Apr 2024 12:01:46 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4017526.1712757455.1@sss.pgh.pa.us> Date: Wed, 10 Apr 2024 09:57:35 -0400 Message-ID: <4017527.1712757455@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Matthias van de Meent writes: > Upthread at [0], Stepan mentioned that we should default to SERIALIZE > when ANALYZE is enabled. I suspect a patch in that direction would > primarily contain updates in the test plan outputs, but I've not yet > worked on that. > Does anyone else have a strong opinion for or against adding SERIALIZE > to the default set of explain features enabled with ANALYZE? I am 100% dead set against that, because it would silently render EXPLAIN outputs from different versions quite non-comparable. regards, tom lane