From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | mark(at)mark(dot)mielke(dot)cc, Alessandro Baretta <a(dot)baretta(at)barettadeit(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Suspending SELECTs |
Date: | 2006-01-18 05:51:58 |
Message-ID: | 43CDD77E.7080902@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane wrote:
> Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> writes:
>
>>SELECT ... FROM table WHERE ... ORDER BY id LIMIT 20;
>
>
>>Suppose this displays records for id 10000 -> 10020.
>>When the user hits next, and page saves id=10020 in the session state
>>and executes:
>
>
>>SELECT ... FROM table WHERE ... AND id > 10020 ORDER BY id LIMIT 20;
>
>
>>Clearly you have to be a little careful about whether to use '>' or '>='
>>depending on whether 'id' is unique or not (to continue using '>' in the
>>non unique case, you can just save and use all the members of the
>>primary key too).
>
>
> This is actually fairly painful to get right for a multi-column key
> at the moment. It'll be much easier once I finish up the
> SQL-spec-row-comparison project.
Right, I think it was actually an Oracle 7.3 based web app (err...
showing age here...) that I used this technique on.
Cheers
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Ahmad Fajar | 2006-01-18 05:54:44 | Re: Multiple Order By Criteria |
Previous Message | Tom Lane | 2006-01-18 04:07:05 | Re: Getting pg to use index on an inherited table (8.1.1) |