Re: Suspending SELECTs - Mailing list pgsql-performance

From Alessandro Baretta
Subject Re: Suspending SELECTs
Date
Msg-id 43CE030E.1070707@barettadeit.com
Whole thread Raw
In response to Re: Suspending SELECTs  (mark@mark.mielke.cc)
Responses Re: Suspending SELECTs  (Tino Wildenhain <tino@wildenhain.de>)
Re: Suspending SELECTs  (mark@mark.mielke.cc)
List pgsql-performance
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)
<http://www.asxcaml.org/>

The FreerP Project
<http://www.freerp.org/>

pgsql-performance by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Suspending SELECTs
Next
From: Tino Wildenhain
Date:
Subject: Re: Suspending SELECTs