Re: Order by (for 15 rows) adds 30 seconds to query time

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Matthew Wakeling" <matthew(at)flymine(dot)org>, "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>
Cc: <jmpoure(at)free(dot)fr>, "PostgreSQL Performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Order by (for 15 rows) adds 30 seconds to query time
Date: 2009-12-02 18:47:27
Message-ID: 4B1661DF020000250002CF61@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Craig Ringer <craig(at)postnewspapers(dot)com(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2009-12-02 20:25:26 Re: Order by (for 15 rows) adds 30 seconds to query time
Previous Message Tom Lane 2009-12-02 17:01:24 Re: Cost of sort/order by not estimated by the query planner