Re: [HACKERS] Solution for LIMIT cost estimation

Philip Warner <pjw@rhyme.com.au>

From: Philip Warner <pjw@rhyme.com.au>
To: Tom Lane <tgl@sss.pgh.pa.us>, "Hiroshi Inoue" <Inoue@tpf.co.jp>
Cc: pgsql-hackers@postgreSQL.org
Date: 2000-02-15T08:08:09Z
Lists: 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   |/