Re: quickly getting the top N rows

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: quickly getting the top N rows
Дата
Msg-id 3785.1191523930@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: quickly getting the top N rows  (Ben <bench@silentmedia.com>)
Ответы Re: quickly getting the top N rows  (Ben <bench@silentmedia.com>)
Список pgsql-performance
Ben <bench@silentmedia.com> writes:
> No, the tables are recently analyzed and there are a couple hundred
> thousand rows in there. But I think I just figured it out.... it's a
> 3-column index, and two columns of that index are the same for every row.
> When I drop those two columns from the ordering restriction, the index
> gets used and things speed up 5 orders of magnitude.

> Maybe the planner is smart enough to think that if a column in the order
> by clause is identical for most rows, then using an index won't help....
> but not smart enough to realize that if said column is at the *end* of the
> order by arguments, after columns which do sort quite well, then it should
> use an index after all.

You're being about as clear as mud here, except that you obviously lied
about what you were doing in your first message.  If you have a planner
problem, show us the *exact* query, the *exact* table definition, and
unfaked EXPLAIN ANALYZE output.

            regards, tom lane

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

Предыдущее
От: Ben
Дата:
Сообщение: Re: quickly getting the top N rows
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Tuning Help - What did I do wrong?