Re: explain analyze rows=%.0f
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Greg Stark <stark@mit.edu>, vignesh C <vignesh21@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>,
"David G. Johnston" <david.g.johnston@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Simon Riggs <simon@2ndquadrant.com>, Ron Mayer <rm_pg@cheapcomplexdevices.com>, Euler Taveira de Oliveira <euler@timbira.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2022-07-07T20:45:19Z
Lists: pgsql-hackers
On Thu, Jul 7, 2022 at 1:21 PM Robert Haas <robertmhaas@gmail.com> wrote: > Nested Loop (actual time=TIME FOR THIS AND ALL CHILDREN rows=THE REAL > ROW COUNT loops=1) > -> Seq Scan on something (actual time=THE TIME IT REALLY TOOK rows=THE > REAL ROW COUNT loops=1) > -> Index Scan using someidx on somethingelse (actual time=NOT REALLY > HOW LONG IT TOOK rows=NOT REALLY HOW MANY ROWS WE GOT loops=HUGE > NUMBER) > > If I'm looking at this plan and trying to find out what's gone wrong, > I want to know how much time got spent in the nested loop, how much > time got spent in the Seq Scan, and how much time got spent in the > Index Scan. It's easy to figure out how much time got spent in the Seq > Scan, but to find out how much time got spent in the Index Scan, I > have to multiply the time by the loop count. I agree that this general state of affairs is very confusing, and seems like something that we should still improve. Just because it's a very old way of presenting the information doesn't mean that it's the best one, or even a particularly good one. Plus you could probably make some kind of concession in the direction of maintaining compatibility with the current approach if you had to. Right? -- Peter Geoghegan
Commits
-
EXPLAIN: Always use two fractional digits for row counts.
- 95dbd827f2ed 18.0 landed
-
Adjust EXPLAIN test case to filter out "Actual Rows" values.
- 44cbba9a7f51 18.0 cited
-
Allow EXPLAIN to indicate fractional rows.
- ddb17e387aa2 18.0 landed
-
Fix pgbench performance issue induced by commit af35fe501.
- fb056564ec5b 18.0 cited