Re: pgsql/src/backend/nodes (copyfuncs.c outfuncs.c print.c)

At 21:03 28/10/00,  wrote:
>
>In a plain SELECT, yes.  In a DECLARE CURSOR, it's currently set up
>to prefer indexscans anyway, LIMIT or no LIMIT (see lines 853 ff in
>src/backend/optimizer/plan/planner.c, current sources).  I think it
>makes sense to have that preference for DECLARE, and what I'm wondering
>is if we need an additional preference when the DECLARE contains a LIMIT
>clause --- and if so, what should that be?

Do you really think it's not such a good idea to have different optimizer
behaviour for SELECT and DECLARE CURSOR? My expectation is that putting a
SELECT statement inside a cursor should not change it's performance. I'd be
interested to know the reasons for your choice.

The simplest solution would be to use the same logic in both cases; if the
correct behaviour is not obvious to you, then our users will be left second
guessing the optimizer once you start introducing several special cases
(LIMIT in SELECT, LIMIT ALL in SELECT, LIMIT in DECLARE etc etc).


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/