Re: explain analyze rows=%.0f - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: explain analyze rows=%.0f
Date
Msg-id CAH2-Wz=PFiqsDsFqeOpxg+SrQ3F0wxZURxTp+vcHh+LCE+yb7A@mail.gmail.com
Whole thread Raw
In response to Re: explain analyze rows=%.0f  (Robert Haas <robertmhaas@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: explain analyze rows=%.0f
Next
From: David Steele
Date:
Subject: Re: remove more archiving overhead