X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id BBF1A528A9 for ; Wed, 18 May 2005 17:20:33 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 61497-02 for ; Wed, 18 May 2005 20:20:26 +0000 (GMT) Received: from mx5.net.nih.gov (mx5.net.nih.gov [165.112.130.36]) by svr1.postgresql.org (Postfix) with ESMTP id A3EF452823 for ; Wed, 18 May 2005 17:20:25 -0300 (ADT) Received: from mx5.net.nih.gov (localhost [127.0.0.1]) by mx5.net.nih.gov (8.12.10/8.11.6) with ESMTP id j4IKKRas026107 for ; Wed, 18 May 2005 16:20:27 -0400 Received: from [128.231.145.14] (holmes.nhgri.nih.gov [128.231.145.14]) by mx5.net.nih.gov (8.12.10/8.11.6) with ESMTP id j4IKKQKd026104; Wed, 18 May 2005 16:20:26 -0400 In-Reply-To: <60mzqsqpku.fsf@dba2.int.libertyrms.com> References: <20050517170636.GC12405@phlogiston.dyndns.org> <428A2E81.2060501@pobox.com> <60mzqsqpku.fsf@dba2.int.libertyrms.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: pgsql-sql@postgresql.org From: Sean Davis Subject: Re: Does Postgresql have a similar pseudo-column "ROWNUM" as Date: Wed, 18 May 2005 16:20:26 -0400 To: Chris Browne X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.004 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200505/157 X-Sequence-Number: 21470 On May 18, 2005, at 3:52 PM, Chris Browne wrote: > alainm@pobox.com (Alain) writes: >> Andrew Sullivan escreveu: >>> On Thu, May 12, 2005 at 01:07:00PM -0600, Dennis.Jiang@thomson.com >>> wrote: >>> >>>> Does Postgresql have a similar pseudo-column "ROWNUM" as Oracle? If >>>> so, we can write the following query: >>> No. What is the purpose of your query? You could use ORDER BY and >>> LIMIT..OFFSET to do what you want. I think. >> >> The problem is probably speed. I have done a lot of tests, and when >> OFFSET gets to a few thousands on a multimega-recs database, it gets >> very very slow... Is there any other to work around that? > > The other way to do this would involve creating a cursor against the > table, and using suitable FETCHes to grab the portions that you > needed. > > In practice, this has seemed to be the relevant answer to what the > application developer actually wanted. > > The common "use case" where I see it is in a web application where > they discover that there are 800K records, and the user only wants a > screenful at a time. > > Establishing a cursor, and having the web app jump around on it, seems > to be the right answer. (Whether it's reasonably implementable by the > developers may be another question, but that's allowed to be a > separate question ;-).) In a web app, I doubt that cursors can be useful because of the stateless nature of web interaction. I'd love to hear otherwise, but.... Sean