Re: EXPLAIN ANALYZE output weird for Top-N Sort

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: EXPLAIN ANALYZE output weird for Top-N Sort
Дата
Msg-id 27498.1415926436@sss.pgh.pa.us
обсуждение исходный текст
Ответ на EXPLAIN ANALYZE output weird for Top-N Sort  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: EXPLAIN ANALYZE output weird for Top-N Sort  (David G Johnston <david.g.johnston@gmail.com>)
Re: EXPLAIN ANALYZE output weird for Top-N Sort  (David G Johnston <david.g.johnston@gmail.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> Limit  (cost=.... rows=20 width=175) (actual time=.... rows=20 loops=1)
>    ->  Sort  (cost=.... rows=568733 width=175) (actual time=....
> rows=20 loops=1)
>          Sort Method: top-N heapsort

> The Sort estimate shows 568733 rows, whereas the actual rows are 20.

[ shrug... ]  The estimated value is the planner's estimate of what would
happen *if you ran the node to completion*, which in practice doesn't
happen because of the LIMIT.  The actual value is, well, the actual value.
We certainly should not munge around the actual value.

We could imagine munging the reported estimates to account for the parent
LIMIT, but that would make it a lot harder to understand the planner's
"thought processes", because the reported estimates would have that much
less to do with the numbers actually used in the internal calculations.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: [GENERAL] Performance issue with libpq prepared queries on 9.3 and 9.4
Следующее
От: David Rowley
Дата:
Сообщение: Re: using custom scan nodes to prototype parallel sequential scan