Re: [HACKERS] Solution for LIMIT cost estimation
От | Philip Warner |
---|---|
Тема | Re: [HACKERS] Solution for LIMIT cost estimation |
Дата | |
Msg-id | 3.0.5.32.20000215190809.034d1b10@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 01:30 15/02/00 -0500, Tom Lane wrote: > >> What about cursors ? >> I heard from Jan that we could specify 'LIMIT ALL' to tell optimizer that >> the response to get first rows is needed. > >Hmm. Right now I have it coded to treat 'LIMIT ALL' the same as >no LIMIT clause, which is the way it ought to work AFAICS. > >DECLARE CURSOR doesn't appear to support OFFSET/LIMIT at all (the >grammar will take the clause, but analyze.c throws it away...). > >I have the LIMIT support in the planner coded to build plans for >DECLARE CURSOR queries on the assumption that 10% of the rows will >be fetched, which is the sort of compromise that will satisfy >nobody ;-). > >A possible answer is to define OFFSET/LIMIT in DECLARE CURSOR as >being simply a hint to the optimizer about how much of the query >result will actually get fetched. This seems a good approach until cursors are fixed. But is there a plan to make cursors support LIMIT properly? Do you know why they ignore the LIMIT clause? Or am I missing something? ---------------------------------------------------------------- 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 по дате отправления: