Re: Planner won't use composite index if there is an order by ????

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Planner won't use composite index if there is an order by ????
Дата
Msg-id 11004.1209083007@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Planner won't use composite index if there is an order by ????  (Dave Cramer <pg@fastcrypt.com>)
Список pgsql-performance
Dave Cramer <pg@fastcrypt.com> writes:
> Any idea why it wouldn't choose the right index ?

It thinks that way is cheaper.  It's estimating its cost at 8381,
whereas selecting all the rows then sorting must take 10131 plus
some time to sort.

The reason why those estimates are so far off from reality is directly
tied to the 400-estimated-vs-2-actual rowcount estimation error.
I'm not sure how much of that could be fixed by raising the stats target
for the table, but that's certainly something to try.

Another thing you should look at is eliminating dependences between
columns.  I'll bet that the "scored_at is not null" condition is either
redundant with the "score in ..." condition, or could be made so (ie
force score to null when scored_at is null).  If you could get rid of
the separate test on scored_at, it'd help to avoid the estimation weak
spot of correlated restrictions.

            regards, tom lane

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

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Planner won't use composite index if there is an order by ????
Следующее
От: Robert Treat
Дата:
Сообщение: Re: Re: [HACKERS] [COMMITTERS] pgsql: Fix TransactionIdIsCurrentTransactionId() to use binary search