At 12:18 27/10/00 -0400, Tom Lane wrote:
>
>1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
>basis of 10%-or-so fetch (I'd consider anywhere from 5% to 25% to be
>just as reasonable, if people want to argue about the exact number;
>perhaps a SET variable is in order?). 10% seems to be a reasonable
>compromise between delivering tuples promptly and not choosing a plan
>that will take forever if the user fetches the whole result.
SET sounds good; will this work on a per-connection basis?
>2. If DECLARE CURSOR contains a specific "LIMIT n" clause, plan on
>the assumption that n tuples will be fetched. For small n this allows
>the user to heavily bias the plan towards fast start. Since the LIMIT
>will actually be enforced by the executor, the user cannot bias the
>plan more heavily than is justified by the number of tuples he's
>intending to fetch, however.
Fine.
>3. If DECLARE CURSOR contains "LIMIT ALL", plan on the assumption that
>all tuples will be fetched, ie, select lowest-total-cost plan.
Good.
>
>Comments?
>
I don't suppose you'd consider 'OPTIMIZE FOR TOTAL COST' and 'OPTIMIZE FOR
FAST START' optimizer hints?
Also, does the change you have made to the executor etc mean that
subselect-with-limit is now possible?
----------------------------------------------------------------
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 |/
