Re: [HACKERS] Solution for LIMIT cost estimation

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Solution for LIMIT cost estimation
Date: 2000-02-16 22:34:43
Message-ID: 3.0.5.32.20000217093443.03588e50@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 10:43 16/02/00 -0500, Tom Lane wrote:
>Philip Warner <pjw(at)rhyme(dot)com(dot)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 |/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Oliver Elphick 2000-02-16 23:00:42 pgaccess and multibyte-enabled libpq
Previous Message Bruce Momjian 2000-02-16 22:29:33 Re: [HACKERS] FYI: BNF for SQL93 and SQL-3