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 по дате отправления: