Re: [HACKERS] Solution for LIMIT cost estimation
От | Philip Warner |
---|---|
Тема | Re: [HACKERS] Solution for LIMIT cost estimation |
Дата | |
Msg-id | 3.0.5.32.20000214164123.0339da10@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: [HACKERS] Solution for LIMIT cost estimation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Solution for LIMIT cost estimation
|
Список | pgsql-hackers |
At 23:24 13/02/00 -0500, Tom Lane wrote: > >Perhaps we should stick to two alternatives: > >1. If LIMIT is present, optimize on an assumption that X% of the >tuples are fetched, where X does *not* depend on the specific >values given for OFFSET or LIMIT. (But we could make X a settable >parameter...) > >2. Optimize using OFFSET+LIMIT as the expected number of tuples to >fetch. Document that varying OFFSET or LIMIT will not necessarily >generate consistent results unless you specify ORDER BY to force a >consistent tuple order. > >I don't really like #1, but I can see where #2 might cause some >unhappiness as well. Comments, opinions? #1 seems pretty nasty as a concept, unless of course this actually reflects the way that PG retrieves rows. My guess is that it will have to retrieve rows 1 to (offset + limit), not (offset) to (offset + limit), so the whole appreximation should be based on #2. [Aside: I suspect that trying to solve problems for people who want to use context free (web) interfaces to retrieve blocks of rows is not a job for the optimizer. It is far more suited to cursors and/or local temporary tables, both of which require some context]. #2 seems more correct, in that it reflects a good estimation, but pessimistic: with good indexes defined, the query may well only need to do a scan of the index to get up to the 'offset-th' row. This, I am sure, must be faster than retrieving all rows up to OFFSET. This leaves two questions: a. Does the optimizer know how to do 'index-only' queries (where all fields are satisfied by the index) b. Just to clarify, OFFSET does affect the tuples actually returned, doesn't it? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: +61-03-5367 7422 | _________ \ Fax: +61-03-5367 7430 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления: