X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id C1E399DC894 for ; Wed, 18 Jan 2006 00:02:29 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 20658-07 for ; Wed, 18 Jan 2006 00:02:27 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 6968F9DC892 for ; Wed, 18 Jan 2006 00:02:27 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k0I42L8P004246; Tue, 17 Jan 2006 23:02:21 -0500 (EST) To: Mark Kirkwood cc: mark@mark.mielke.cc, Alessandro Baretta , pgsql-performance@postgresql.org Subject: Re: Suspending SELECTs In-reply-to: <43CD8B45.4090907@paradise.net.nz> References: <43CB71AC.20203@barettadeit.com> <9766.1137433907@sss.pgh.pa.us> <43CD4BD0.9090807@barettadeit.com> <20060117211259.GA13926@mark.mielke.cc> <43CD8B45.4090907@paradise.net.nz> Comments: In-reply-to Mark Kirkwood message dated "Wed, 18 Jan 2006 13:26:45 +1300" Date: Tue, 17 Jan 2006 23:02:21 -0500 Message-ID: <4245.1137556941@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.091 required=5 tests=[AWL=0.091] X-Spam-Score: 0.091 X-Spam-Level: X-Archive-Number: 200601/283 X-Sequence-Number: 16761 Mark Kirkwood 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