Date: Tue, 17 Jan 2006 15:04:41 -0500
From: Michael Stone <mstone+postgres@mathom.us>
Subject: Re: Suspending SELECTs
In-reply-to: <43CD4BD0.9090807@barettadeit.com>
To: pgsql-performance@postgresql.org
Mail-followup-to: pgsql-performance@postgresql.org
Message-id: <20060117200441.GB1408@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-disposition: inline
References: <43CB71AC.20203@barettadeit.com> <9766.1137433907@sss.pgh.pa.us>
	<43CD4BD0.9090807@barettadeit.com>
User-Agent: Mutt/1.5.11

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.

I don't understand why it is better to rework the db instead of just
having the web middleware keep track of what cursors are associated with
what sessions?

Mike Stone