Re: Suspending SELECTs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
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 04:02:21
Message-ID: 4245.1137556941@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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. See this thread for background:
http://archives.postgresql.org/pgsql-performance/2004-07/msg00188.php

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-01-18 04:07:05 Re: Getting pg to use index on an inherited table (8.1.1)
Previous Message Craig A. James 2006-01-18 03:43:54 Re: Suspending SELECTs