Re: V18 change on EXPLAIN ANALYZE
От | Tom Lane |
---|---|
Тема | Re: V18 change on EXPLAIN ANALYZE |
Дата | |
Msg-id | 34604.1758921116@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: V18 change on EXPLAIN ANALYZE (Maciek Sakrejda <m.sakrejda@gmail.com>) |
Ответы |
Re: V18 change on EXPLAIN ANALYZE
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: