| From: | Michael Stone <mstone+postgres(at)mathom(dot)us> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Suspending SELECTs |
| Date: | 2006-01-17 20:04:41 |
| Message-ID: | 20060117200441.GB1408@mathom.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alessandro Baretta | 2006-01-17 20:06:53 | Re: Suspending SELECTs |
| Previous Message | Yantao Shi | 2006-01-17 20:00:37 | wildcard search performance with "like" |