From: Tom Lane <tgl@sss.pgh.pa.us>
To: maciek@sakrejda.org, Maciek Sakrejda <m.sakrejda@gmail.com>
cc: Robert Haas <robertmhaas@gmail.com>, Marcos Pegoraro <marcos@f10.com.br>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: V18 change on EXPLAIN ANALYZE
In-reply-to: 
 <CAOtHd0BJpzox6iW3Lm3Rcut8edeR+4xfW-7M_gWMRdkhp0oRxw@mail.gmail.com>
References: 
 <CAB-JLwYCgdiB=trauAV1HN5rAWQdvDGgaaY_mqziN88pBTvqqg@mail.gmail.com>
 <CAOtHd0BJpzox6iW3Lm3Rcut8edeR+4xfW-7M_gWMRdkhp0oRxw@mail.gmail.com>
Comments: In-reply-to Maciek Sakrejda <m.sakrejda@gmail.com>
	message dated "Fri, 26 Sep 2025 14:01:37 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <34603.1758921116.1@sss.pgh.pa.us>
Date: Fri, 26 Sep 2025 17:11:56 -0400
Message-ID: <34604.1758921116@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/34604.1758921116%40sss.pgh.pa.us>
Precedence: bulk

Maciek Sakrejda <m.sakrejda@gmail.com> writes:
> The page you link says

>     In some query plans, it is possible for a subplan node to be
> executed more than once. For example, the inner index scan will be
> executed once per outer row in the above nested-loop plan. In such
> cases, the loops value reports the total number of executions of the
> node, and the actual time and rows values shown are averages
> per-execution. This is done to make the numbers comparable with the
> way that the cost estimates are shown. Multiply by the loops value to
> get the total time actually spent in the node. In the above example,
> we spent a total of 0.030 milliseconds executing the index scans on
> tenk2.

> in the second paragraph after the example in this section. Do you
> think that's not sufficiently clear?

It's not wrong, but it feels a little incomplete now.  Maybe change
the last two sentences to

Multiply by the loops value to get the total time actually spent in
the node and the total number of rows processed by the node across all
executions. In the above example, we spent a total of 0.030
milliseconds executing the index scans on tenk2, and they handled a
total of 10 rows.

A bigger gap in perform.sgml is that it doesn't address parallel
query cases at all AFAICS.  I think that was one of the main drivers
of this change, so it feels a little sad that it's not covered here.

			regards, tom lane