Re: quickly getting the top N rows

Поиск
Список
Период
Сортировка
Искать
От
Ben
Тема
Re: quickly getting the top N rows
Дата
Msg-id
Pine.LNX.4.64.0710041414590.30864@localhost.localdomain
Ответ на
Список
Дерево обсуждения
quickly getting the top N rows Ben <bench@silentmedia.com>
Re: quickly getting the top N rows Mark Lewis <mark.lewis@mir3.com>
Re: quickly getting the top N rows Bill Moran <wmoran@collaborativefusion.com>
Re: quickly getting the top N rows Ben <bench@silentmedia.com>
Re: quickly getting the top N rows Tom Lane <tgl@sss.pgh.pa.us>
Re: quickly getting the top N rows Ben <bench@silentmedia.com>
Re: quickly getting the top N rows Simon Riggs <simon@2ndquadrant.com>
Re: quickly getting the top N rows Ben <bench@silentmedia.com>
Re: quickly getting the top N rows Tom Lane <tgl@sss.pgh.pa.us>
Re: quickly getting the top N rows Ben <bench@silentmedia.com>
Re: quickly getting the top N rows "Scott Marlowe" <scott.marlowe@gmail.com>
Re: quickly getting the top N rows Richard Huxton <dev@archonet.com>
Re: quickly getting the top N rows Andreas Kretschmer <akretschmer@spamfence.net>
Re: quickly getting the top N rows "Scott Marlowe" <scott.marlowe@gmail.com>


On Thu, 4 Oct 2007, Tom Lane wrote:

> There's some limited smarts in there about deciding that leading columns
> of an index don't matter to the sort ordering if they're constrained to
> just one value by the query.  But it doesn't catch the case you need,
> which is that columns of an ORDER BY request are no-ops when they're
> constrained to just one value.

Oh, no, that explains it perfectly, because that's precisely the case I 
have - I dropped the columns from the ordering, but not the where clause. 
Thanks, now I understand the current behavior.
В списке pgsql-performance по дате отправления
От: Henrik
Дата:
От: Alvaro Herrera
Дата:
FAQ