From: Tom Lane <tgl@sss.pgh.pa.us>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: stepan rutz <stepan.rutz@gmx.de>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Detoasting optionally to make Explain-Analyze less misleading
Date: Tue, 12 Sep 2023 11:26:39 -0400
Message-ID: <2802772.1694532399@sss.pgh.pa.us> (raw)
In-Reply-To: <CAEze2WhXYCJ8=ZBTbRTp9rGbvju9LK6UO7hodECKWgU-_a==aw@mail.gmail.com>
References: <ca0adb0e-fa4e-c37e-1cd7-91170b18cae1@gmx.de>
<CAEze2WhXYCJ8=ZBTbRTp9rGbvju9LK6UO7hodECKWgU-_a==aw@mail.gmail.com>
Matthias van de Meent <boekewurm+postgres@gmail.com> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, boekewurm+postgres@gmail.com, stepan.rutz@gmx.de
Subject: Re: Detoasting optionally to make Explain-Analyze less misleading
In-Reply-To: <2802772.1694532399@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox