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 89C699DC833 for ; Wed, 18 Jan 2006 04:57:39 -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 71045-09 for ; Wed, 18 Jan 2006 04:57:38 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.barettadeit.com (unknown [213.255.109.130]) by postgresql.org (Postfix) with ESMTP id F0E3C9DC9C3 for ; Wed, 18 Jan 2006 04:57:34 -0400 (AST) Received: from [10.1.0.20] (unknown [10.1.0.20]) by mail.barettadeit.com (Postfix) with ESMTP id BD3CD40BF69; Wed, 18 Jan 2006 10:02:03 +0100 (CET) Message-ID: <43CE030E.1070707@barettadeit.com> Date: Wed, 18 Jan 2006 09:57:50 +0100 From: Alessandro Baretta User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mark@mark.mielke.cc Cc: Tom Lane , pgsql-performance@postgresql.org Subject: Re: Suspending SELECTs References: <43CB71AC.20203@barettadeit.com> <9766.1137433907@sss.pgh.pa.us> <43CD4BD0.9090807@barettadeit.com> <20060117211259.GA13926@mark.mielke.cc> In-Reply-To: <20060117211259.GA13926@mark.mielke.cc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.12 required=5 tests=[AWL=0.120] X-Spam-Score: 0.12 X-Spam-Level: X-Archive-Number: 200601/287 X-Sequence-Number: 16765 mark@mark.mielke.cc wrote: > On Tue, Jan 17, 2006 at 08:56:00PM +0100, Alessandro Baretta wrote: > >>I understand most of these issues, and expected this kind of reply. Please, >>allow me to insist that we reason on this problem and try to find a >>solution. My reason for doing so is that the future software industry is >>likely to see more and more web applications retrieving data from virtually >>endless databases, and in such contexts, it is sensible to ask the final >>client--the web client--to store the "cursor state", because web >>interaction is intrinsically asynchronous, and you cannot count on users >>logging out when they're done, releasing resources allocated to them. Think >>of Google. > > > What is wrong with LIMIT and OFFSET? I assume your results are ordered > in some manner. It looks like this is the only possible solution at present--and in the future, too--but it has a tremendouse performance impact on queries returning thousands of rows. Alex -- ********************************************************************* http://www.barettadeit.com/ Baretta DE&IT A division of Baretta SRL tel. +39 02 370 111 55 fax. +39 02 370 111 54 Our technology: The Application System/Xcaml (AS/Xcaml) The FreerP Project