Re: Suspending SELECTs

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

In response to

Browse pgsql-performance by date

  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)