| From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
|---|---|
| To: | "'Philip Warner'" <pjw(at)rhyme(dot)com(dot)au>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | AW: LIMIT in DECLARE CURSOR: request for comments |
| Date: | 2000-10-31 13:14:15 |
| Message-ID: | 11C1E6749A55D411A9670001FA6879633680D9@sdexcsrv1.f000.d0188.sd.spardat.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> >So I think if you want to make optimization decisions based on cursors
> >being used versus a "normal" select, then the only thing you can safely
> >take into account is the network roundtrip and client processing per
> >fetch, but that might be as random as anything.
>
> Which is why I like the client being able to ask the
> optimizer for certain kinds of solutions *explicitly*.
Yes, something like:
set optimization to [first_rows|all_rows]
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Philip Warner | 2000-10-31 13:23:53 | Re: AW: LIMIT in DECLARE CURSOR: request for comments |
| Previous Message | Adriaan Joubert | 2000-10-31 11:51:34 | Re: Re: BIT/BIT VARYING status |