| From: | Alessandro Baretta <a(dot)baretta(at)barettadeit(dot)com> |
|---|---|
| To: | mark(at)mark(dot)mielke(dot)cc |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Suspending SELECTs |
| Date: | 2006-01-18 08:57:50 |
| Message-ID: | 43CE030E.1070707@barettadeit.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
mark(at)mark(dot)mielke(dot)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/>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tino Wildenhain | 2006-01-18 09:08:25 | Re: Suspending SELECTs |
| Previous Message | Ahmad Fajar | 2006-01-18 05:54:44 | Re: Multiple Order By Criteria |