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

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Order by (for 15 rows) adds 30 seconds to query time
Дата
Msg-id 4B1661DF020000250002CF61@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Order by (for 15 rows) adds 30 seconds to query time  (Craig Ringer <craig@postnewspapers.com.au>)
Ответы Re: Order by (for 15 rows) adds 30 seconds to query time  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Cost of sort/order by not estimated by the query planner
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Order by (for 15 rows) adds 30 seconds to query time