Re: explain analyze rows=%.0f
От | Peter Geoghegan |
---|---|
Тема | Re: explain analyze rows=%.0f |
Дата | |
Msg-id | CAH2-Wz=PFiqsDsFqeOpxg+SrQ3F0wxZURxTp+vcHh+LCE+yb7A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: explain analyze rows=%.0f (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: