From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Cc: | Alessandro Baretta <a(dot)baretta(at)barettadeit(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Suspending SELECTs |
Date: | 2006-01-17 22:59:02 |
Message-ID: | 200601171459.02398.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | J | 2006-01-17 23:03:04 | Re: Multiple Order By Criteria |
Previous Message | Fredrick O Jackson | 2006-01-17 22:57:06 | Re: Multiple Order By Criteria |