Re: Implementing next 30 (or so) rows "sliding window"

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: Implementing next 30 (or so) rows "sliding window"
Дата
Msg-id dcc563d10912081251x6b8d5aadif8c12c46a48e0874@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Implementing next 30 (or so) rows "sliding window"  (Allan Kamau <kamauallan@gmail.com>)
Ответы Re: Implementing next 30 (or so) rows "sliding window"  (Jaime Casanova <jcasanov@systemguards.com.ec>)
Список pgsql-general
On Tue, Dec 8, 2009 at 12:12 PM, Allan Kamau <kamauallan@gmail.com> wrote:
> Hi,
> I did follow the basic advise and consulted the documentation for
> "SELECT" and came across "[ FETCH { FIRST | NEXT } [ count ] { ROW |
> ROWS } ONLY]" clause which seems to satisfy my requirement.

This is a cursor, which is one of two very basic ways of doing this.
IF you have presistent objects in your app layer, you can declare a
cursor and reuse it as your user moves through the list, one page
after another.  If you do not have some kind of persistence layer for
db objects, then declaring a cursor each time a user navigates to
another page won't really gain you much, and adds complexity.

In that instance offset / limit work fairly well.  As another poster
mentions, it gets slow with large offsets.  However, most of the time,
like in forum software, you don't go dragging to page 258 of a result
set very often, so a small delay when doing so is usually acceptable.

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

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: how to allow a sysid to be a superuser?
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: Counts and percentages and such