From: mark@mark.mielke.cc
To: Alessandro Baretta <a.baretta@barettadeit.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: Suspending SELECTs
Date: Tue, 17 Jan 2006 16:12:59 -0500
Message-ID: <20060117211259.GA13926@mark.mielke.cc> (raw)
In-Reply-To: <43CD4BD0.9090807@barettadeit.com>
References: <43CB71AC.20203@barettadeit.com>
<9766.1137433907@sss.pgh.pa.us>
<43CD4BD0.9090807@barettadeit.com>
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.
Especially with web users, who become bored if the page doesn't flicker
in a way that appeals to them, how could one have any expectation that
the cursor would ever be useful at all?
As a 'general' solution, I think optimizing the case where the same
query is executed multiple times, with only the LIMIT and OFFSET
parameters changing, would be a better bang for the buck. I'm thinking
along the lines of materialized views, for queries executed more than
a dozen times in a short length of time... :-)
In the mean time, I successfully use LIMIT and OFFSET without such an
optimization, and things have been fine for me.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mark@mark.mielke.cc, a.baretta@barettadeit.com, tgl@sss.pgh.pa.us
Subject: Re: Suspending SELECTs
In-Reply-To: <20060117211259.GA13926@mark.mielke.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox