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 1qg5Mk-00EPyG-W2 for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Sep 2023 15:31:50 +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 1qg5Mj-009Y5N-Hy for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Sep 2023 15:31:49 +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 1qg5Mj-009Y53-7Y for pgsql-hackers@lists.postgresql.org; Tue, 12 Sep 2023 15:31:49 +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.94.2) (envelope-from ) id 1qg5Mf-004AZF-Oc for pgsql-hackers@postgresql.org; Tue, 12 Sep 2023 15:31:47 +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 38CFQdcB2802773; Tue, 12 Sep 2023 11:26:39 -0400 From: Tom Lane To: Matthias van de Meent cc: stepan rutz , pgsql-hackers@postgresql.org Subject: Re: Detoasting optionally to make Explain-Analyze less misleading In-reply-to: References: Comments: In-reply-to Matthias van de Meent message dated "Tue, 12 Sep 2023 14:25:40 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2802771.1694532399.1@sss.pgh.pa.us> Date: Tue, 12 Sep 2023 11:26:39 -0400 Message-ID: <2802772.1694532399@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: > Hmm, maybe we should measure the overhead of serializing the tuples instead. > The difference between your patch and "serializing the tuples, but not > sending them" is that serializing also does the detoasting, but also > includes any time spent in the serialization functions of the type. So > an option "SERIALIZE" which measures all the time the server spent on > the query (except the final step of sending the bytes to the client) > would likely be more useful than "just" detoasting. +1, that was my immediate reaction to the proposal as well. Some output functions are far from cheap. Doing only the detoast part seems like it's still misleading. Do we need to go as far as offering both text-output and binary-output options? regards, tom lane