From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: stepan rutz <stepan.rutz@gmx.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Detoasting optionally to make Explain-Analyze less misleading
Date: Thu, 2 Nov 2023 22:25:16 +0100
Message-ID: <886b209f-8736-9cf2-ab9c-89870dea7bd8@enterprisedb.com> (raw)
In-Reply-To: <CAEze2WjrZST8YEhV_oYXzC8y=P5aRGCMe_QpwhdK1PmNpjCeWQ@mail.gmail.com>
References: <ca0adb0e-fa4e-c37e-1cd7-91170b18cae1@gmx.de>
<CAEze2WhXYCJ8=ZBTbRTp9rGbvju9LK6UO7hodECKWgU-_a==aw@mail.gmail.com>
<2802772.1694532399@sss.pgh.pa.us>
<ce7edfd9-dcc5-2203-5ce5-051ca229b75a@gmx.de>
<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>
<CAEze2WjrZST8YEhV_oYXzC8y=P5aRGCMe_QpwhdK1PmNpjCeWQ@mail.gmail.com>
On 11/2/23 21:02, Matthias van de Meent wrote:
> On Thu, 2 Nov 2023 at 20:32, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:
>> On 11/2/23 20:09, stepan rutz wrote:
>>> db1=# explain (analyze, serialize) select * from test;
>>> QUERY PLAN
>>> ---------------------------------------------------------------------------------------------------
>>> Seq Scan on test (cost=0.00..22.00 rows=1200 width=40) (actual
>>> time=0.023..0.027 rows=1 loops=1)
>>> Planning Time: 0.077 ms
>>> Execution Time: 303.281 ms
>>> Serialized Bytes: 78888953 Bytes. Mode Text. Bandwidth 248.068 MB/sec
>> [...]
>> BTW if you really want to print amount of memory, maybe print it in
>> kilobytes, like every other place in explain.c?
>
> Isn't node width in bytes, or is it an opaque value not to be
> interpreted by users? I've never really investigated that part of
> Postgres' explain output...
>
Right, "width=" is always in bytes. But fields like amount of sorted
data is in kB, and this seems closer to that.
>> Also, explain generally
>> prints stuff in "key: value" style (in text format).
>
> That'd be key: metrickey=metricvalue for expanded values like those in
> plan nodes and the buffer usage, no?
>
Possibly. But the proposed output does neither. Also, it starts with
"Serialized Bytes" but then prints info about bandwidth.
>>> Serialized Bytes: 78888953 Bytes. Mode Text. Bandwidth 248.068 MB/sec
>
> I was thinking more along the lines of something like this:
>
> [...]
> Execution Time: xxx ms
> Serialization: time=yyy.yyy (in ms) size=yyy (in KiB, or B) mode=text
> (or binary)
> > This is significantly different from your output, as it doesn't hide
> the measured time behind a lossy calculation of bandwidth, but gives
> the measured data to the user; allowing them to derive their own
> precise bandwidth if they're so inclined.
>
Might work. I'm still not convinced we need to include the mode, or that
the size is that interesting/useful, though.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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: tomas.vondra@enterprisedb.com, boekewurm+postgres@gmail.com, stepan.rutz@gmx.de, tgl@sss.pgh.pa.us
Subject: Re: Detoasting optionally to make Explain-Analyze less misleading
In-Reply-To: <886b209f-8736-9cf2-ab9c-89870dea7bd8@enterprisedb.com>
* 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