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
Ответ на
Re: quickly getting the top N rows (Tom Lane)
Список
Дерево обсуждения
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 по дате отправления
От: Alvaro Herrera
Дата: