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 |/
