Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1
Дата
Msg-id 26708.1300033481@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1  ("John Surcombe" <John.Surcombe@digimap.gg>)
Ответы Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
"John Surcombe" <John.Surcombe@digimap.gg> writes:
> When we 'EXPLAIN' this query, PostgreSQL says it is using the index
> idx_receiveddatetime.  The way the application is designed means that in
> virtually all cases the query will have to scan a very long way into
> idx_receiveddatetime to find the first record where userid = 311369000.
> If however we delete the idx_receiveddatetime index, the query uses the
> idx_userid_receiveddatetime index, and the query only takes a few
> milliseconds.

That's just bizarre ... it knows the index is applicable, and the cost
estimates clearly favor the better index, so why did it pick the worse
one?

I tried to duplicate this locally, without success, so there's some
contributing factor you've neglected to mention.  Can you put together a
self-contained test case that acts like this?

            regards, tom lane

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

Предыдущее
От: Jeremy
Дата:
Сообщение: Re: Planner wrongly shuns multi-column index for select .. order by col1, col2 limit 1
Следующее
От: runner
Дата:
Сообщение: Re: Tuning massive UPDATES and GROUP BY's?