| From: | "Joost Kraaijeveld" <J(dot)Kraaijeveld(at)Askesis(dot)nl> |
|---|---|
| To: | "PFC" <lists(at)boutiquenumerique(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Pgsql-Performance (E-mail)" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Retry: Is this possible / slow performance? |
| Date: | 2005-02-07 19:27:18 |
| Message-ID: | A3D1526C98B7C1409A687E0943EAC410605EF3@obelix.askesis.nl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
>> The best solution is probably to put a LIMIT into the DECLARE CURSOR,
>> so that the planner can see how much you intend to fetch.
I assume that this limits the resultset to a LIMIT. That is not what I was hoping for. I was hoping for a way to scrolll throught the whole tables with orders.
I have tested, and if one really wants the whole table the query with "set enable_seqscan = on" lasts 137 secs, the query with "set enable_seqscan = off" lasts 473 secs, so (alas), the planner is right.
I sure would like to have ISAM like behaviour once in a while.
Groeten,
Joost Kraaijeveld
Askesis B.V.
Molukkenstraat 14
6524NB Nijmegen
tel: 024-3888063 / 06-51855277
fax: 024-3608416
e-mail: J(dot)Kraaijeveld(at)Askesis(dot)nl
web: www.askesis.nl
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2005-02-07 19:52:53 | Re: Retry: Is this possible / slow performance? |
| Previous Message | PFC | 2005-02-07 18:16:47 | Re: Retry: Is this possible / slow performance? |