| From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | Andrus <kobruleht2(at)hot(dot)ee> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: limit clause produces wrong query plan |
| Date: | 2008-11-24 19:23:10 |
| Message-ID: | dcc563d10811241123q5b481020w57ac6622301c1d65@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Nov 24, 2008 at 10:26 AM, Andrus <kobruleht2(at)hot(dot)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;
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brad Nicholson | 2008-11-24 19:45:22 | Re: Monitoring buffercache... |
| Previous Message | Kevin Kempter | 2008-11-24 18:43:56 | Monitoring buffercache... |