| From: | Tino Wildenhain <tino(at)wildenhain(dot)de> |
|---|---|
| To: | Alessandro Baretta <a(dot)baretta(at)barettadeit(dot)com> |
| Cc: | mark(at)mark(dot)mielke(dot)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 09:08:25 |
| Message-ID: | 43CE0589.3000003@wildenhain.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Alessandro Baretta schrieb:
> mark(at)mark(dot)mielke(dot)cc wrote:
>
...
>
> 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.
>
Well actually one of the better solutions would be persistent cursors
(and therefore connection pooling). I bet this is easier then
fiddling with the problems of offset/limit and inventing even more
compex caching in the application.
Just my 0.02c
++Tino
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marcos | 2006-01-18 09:10:30 | Simple Question of Performance ILIKE or Lower |
| Previous Message | Alessandro Baretta | 2006-01-18 08:57:50 | Re: Suspending SELECTs |