Re: [HACKERS] Solution for LIMIT cost estimation
От | Philip Warner |
---|---|
Тема | Re: [HACKERS] Solution for LIMIT cost estimation |
Дата | |
Msg-id | 3.0.5.32.20000217093443.03588e50@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: [HACKERS] Solution for LIMIT cost estimation (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
At 10:43 16/02/00 -0500, Tom Lane wrote: >Philip Warner <pjw@rhyme.com.au> writes: >>> 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? > >Should they obey LIMIT? MOVE/FETCH seems like a considerably more >flexible interface, so I'm not quite sure why anyone would want to >use LIMIT in a cursor. I agree; but see below. >Still, it seems kind of inconsistent that cursors ignore LIMIT. >I don't know for sure why it was done that way. It's the inconsistency that bothers me: if I run a SELECT statement, then put it in a cursor, I should get the same rows returned. Ths current behaviour should probably be considered a bug. ---------------------------------------------------------------- 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 по дате отправления: