From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: pgsql-performance@postgresql.org
Subject: Re: Suspending SELECTs
Date: Tue, 17 Jan 2006 14:59:02 -0800
User-Agent: KMail/1.8
Cc: Alessandro Baretta <a.baretta@barettadeit.com>,
	Tom Lane <tgl@sss.pgh.pa.us>
References: <43CB71AC.20203@barettadeit.com> <9766.1137433907@sss.pgh.pa.us>
	<43CD4BD0.9090807@barettadeit.com>
In-Reply-To: <43CD4BD0.9090807@barettadeit.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200601171459.02398.josh@agliodbs.com>

Alessandro,

> 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 think you're trying to use an unreasonable difficult method to solve a 
problem that's already been solved multiple times.  What you want is 
called "query caching."   There are about 800 different ways to do this on 
the middleware or application layer which are 1000% easier than what 
you're proposing.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco