pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedReading explain plans- row estimates/actuals on lower nodes vs next level up
2+ messages / 2 participants
[nested] [flat]
* Reading explain plans- row estimates/actuals on lower nodes vs next level up
@ 2019-10-17 21:15 Michael Lewis <mlewis@entrata.com>
2019-10-18 00:13 ` Re: Reading explain plans- row estimates/actuals on lower nodes vs next level up Tomas Vondra <tomas.vondra@2ndquadrant.com>
0 siblings, 1 reply; 2+ messages in thread
From: Michael Lewis @ 2019-10-17 21:15 UTC (permalink / raw)
To: pgsql-performance
https://explain.depesz.com/s/Caa5
I am looking at this explain analyze output and seeing a nested loop
towards the lowest levels with pretty bad estimate vs actual (2.3k vs 99k),
but the things that feed that nested loop seem like the estimates are
rather close (index scans with 11 estimated vs 30 actual and 3350 vs
3320)... why does the higher node have such a different estimate vs actual
ratio?
*Michael Lewis | Software Engineer*
*Entrata*
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Reading explain plans- row estimates/actuals on lower nodes vs next level up
2019-10-17 21:15 Reading explain plans- row estimates/actuals on lower nodes vs next level up Michael Lewis <mlewis@entrata.com>
@ 2019-10-18 00:13 ` Tomas Vondra <tomas.vondra@2ndquadrant.com>
0 siblings, 0 replies; 2+ messages in thread
From: Tomas Vondra @ 2019-10-18 00:13 UTC (permalink / raw)
To: Michael Lewis <mlewis@entrata.com>; +Cc: pgsql-performance
On Thu, Oct 17, 2019 at 03:15:21PM -0600, Michael Lewis wrote:
>https://explain.depesz.com/s/Caa5
>
>I am looking at this explain analyze output and seeing a nested loop
>towards the lowest levels with pretty bad estimate vs actual (2.3k vs 99k),
>but the things that feed that nested loop seem like the estimates are
>rather close (index scans with 11 estimated vs 30 actual and 3350 vs
>3320)... why does the higher node have such a different estimate vs actual
>ratio?
>
This is usually a sign of non-uniform distribution for the join columns,
and/or correlation between sides of the join.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2019-10-18 00:13 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-10-17 21:15 Reading explain plans- row estimates/actuals on lower nodes vs next level up Michael Lewis <mlewis@entrata.com>
2019-10-18 00:13 ` Tomas Vondra <tomas.vondra@2ndquadrant.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox