Re: [SQL] OFFSET impact on Performance???

Поиск
Список
Период
Сортировка
От Alex Turner
Тема Re: [SQL] OFFSET impact on Performance???
Дата
Msg-id 33c6269f05012008391490448b@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [SQL] OFFSET impact on Performance???  (Richard Huxton <dev@archonet.com>)
Ответы Re: [SQL] OFFSET impact on Performance???  (Richard Huxton <dev@archonet.com>)
Re: [SQL] OFFSET impact on Performance???  (Greg Stark <gsstark@mit.edu>)
Список pgsql-performance
I am also very interesting in this very question.. Is there any way to
declare a persistant cursor that remains open between pg sessions?
This would be better than a temp table because you would not have to
do the initial select and insert into a fresh table and incur those IO
costs, which are often very heavy, and the reason why one would want
to use a cursor.

Alex Turner
NetEconomist


On Thu, 20 Jan 2005 15:20:59 +0000, Richard Huxton <dev@archonet.com> wrote:
> Andrei Bintintan wrote:
> >> If you're using this to provide "pages" of results, could you use a
> >> cursor?
> >
> > What do you mean by that? Cursor?
> >
> > Yes I'm using this to provide "pages", but If I jump to the last pages
> > it goes very slow.
>
> DECLARE mycursor CURSOR FOR SELECT * FROM ...
> FETCH FORWARD 10 IN mycursor;
> CLOSE mycursor;
>
> Repeated FETCHes would let you step through your results. That won't
> work if you have a web-app making repeated connections.
>
> If you've got a web-application then you'll probably want to insert the
> results into a cache table for later use.
>
> --
>    Richard Huxton
>    Archonet Ltd
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>

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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re:
Следующее
От: Greg Stark
Дата:
Сообщение: Re: PostgreSQL clustering VS MySQL clustering