Re: Order by (for 15 rows) adds 30 seconds to query time - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: Order by (for 15 rows) adds 30 seconds to query time
Date
Msg-id 4B1661DF020000250002CF61@gw.wicourts.gov
Whole thread Raw
In response to Re: Order by (for 15 rows) adds 30 seconds to query time  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: Order by (for 15 rows) adds 30 seconds to query time
List pgsql-performance
Craig Ringer <craig@postnewspapers.com.au> wrote:

> Some of those tables are views composed of multiple unions, too,
> by the looks of things.
>
> Doesn't the planner have some ... issues ... with estimation of
> row counts on joins over unions? Or is my memory just more faulty
> than usual?

So far I can't tell if it's views with unions or (as I suspect)
inheritance.  The views and tables shown so far reference other
objects not yet shown:

core.inventory
h.location
h.actor

However, I'm pretty sure that the problem is that the estimated row
count explodes for no reason that I can see when the "Nested Loop
Left Join" has an "Append" node from a parent table on the right.

28 rows joined to a 4 row append yields 51160 rows?
51160 rows joined to a 2 row append yields 203176856 rows?
203176856 rows joined to a 2 row append yields 806903677108 rows?

Something seems funny with the math.  I would have expected 28 times
4 times 2 times 2, equaling 448.  Still higher than 15, but only by
one order of magnitude -- where it might still make relatively sane
plan choices.

-Kevin

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cost of sort/order by not estimated by the query planner
Next
From: Tom Lane
Date:
Subject: Re: Order by (for 15 rows) adds 30 seconds to query time