Re: Re: [GENERAL] question (or feature-request): over ( partition by ... order by LIMIT N)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Re: [GENERAL] question (or feature-request): over ( partition by ... order by LIMIT N)
Дата
Msg-id 603c8f071003251550h3a93b069u30246458e6a2c46d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] question (or feature-request): over ( partition by ... order by LIMIT N)  (David Fetter <david@fetter.org>)
Список pgsql-hackers
On Thu, Mar 25, 2010 at 5:17 PM, David Fetter <david@fetter.org> wrote:
> On Wed, Mar 24, 2010 at 06:31:59PM +0100, A. Kretschmer wrote:
>> Hello @all,
>>
>> I know, i can do:
>>
>> select * from (select ... row_number() over (...) ...) foo where
>> row_number < N
>>
>> to limit the rows per group, but the inner select has to retrieve
>> the whole set of records and in the outer select most of them
>> discarded.
>
> That sounds like the optimizer's falling down on the job.  Would this
> be difficult to fix?

I may not be the best person to offer an opinion on this topic, but it
sounds tricky to me.  I think it would need some kind of extremely
specific special-case logic.  The planner would have to recognize
row_number() < n, row_number() <= n, and row_number = n as special
cases indicating that n-1, n, and n records respectively should be
expected to be fetched from the partition.  And you might also worry
about n > row_number(), and n >= row_number().

It might be worth doing because I suspect that is actually going to be
a fairly common type of query, but some thought needs to be given to
how to do it without resorting to abject kludgery.

...Robert


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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: [GENERAL] question (or feature-request): over ( partition by ... order by LIMIT N)
Следующее
От: Thom Brown
Дата:
Сообщение: Remove ROW | ROWS from OFFSET and FETCH