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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] FYI: BNF for SQL93 and SQL-3
Следующее
От: "Oliver Elphick"
Дата:
Сообщение: pgaccess and multibyte-enabled libpq