Re: limit clause produces wrong query plan

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: limit clause produces wrong query plan
Дата
Msg-id dcc563d10811241123q5b481020w57ac6622301c1d65@mail.gmail.com
обсуждение исходный текст
Ответ на Re: limit clause produces wrong query plan  ("Andrus" <kobruleht2@hot.ee>)
Ответы Re: limit clause produces wrong query plan  ("Andrus" <kobruleht2@hot.ee>)
Re: limit clause produces wrong query plan  (Scott Carey <scott@richrelevance.com>)
Список pgsql-performance
On Mon, Nov 24, 2008 at 10:26 AM, Andrus <kobruleht2@hot.ee> wrote:
>> it was veery fast. To be honest I do not know what is happening?!
>
> This is really weird.
> It seems that PostgreSql OFFSET / LIMIT are not optimized and thus typical
> paging queries

And how exactly should it be optimized?  If a query is even moderately
interesting, with a few joins and a where clause, postgresql HAS to
create the rows that come before your offset in order to assure that
it's giving you the right rows.

> SELECT ... FROM bigtable ORDER BY intprimarykey OFFSET pageno*100 LIMIT 100

This will get progressively slower as pageno goes up.

> SELECT ... FROM bigtable ORDER BY intprimarykey OFFSET 0 LIMIT 100

That should be plenty fast.

> cannot be used in PostgreSql at all for big tables.

Can't be used in any real database with any real complexity to its query either.

> Do you have any idea how to fix this ?

A standard workaround is to use some kind of sequential, or nearly so,
id field, and then use between on that field.

select * from table where idfield between x and x+100;

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

Предыдущее
От: "Andrus"
Дата:
Сообщение: Re: limit clause produces wrong query plan
Следующее
От: Brad Nicholson
Дата:
Сообщение: Re: Monitoring buffercache...