Re: [HACKERS] What about LIMIT in SELECT ? - Mailing list pgsql-hackers

From jwieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] What about LIMIT in SELECT ?
Date
Msg-id m0zVCaT-000EBPC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to RE: [HACKERS] What about LIMIT in SELECT ?  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-hackers
Hiroshi Inoue wrote:

> When using cursors,in most cases the response to get first(next) rows
> is necessary for me,not the throughput.
> How can we tell PostgreSQL optimzer that the response is necessary ?

    With my LIMIT patch, the offset and the row count are part of
    the querytree. And if a LIMIT is given, the limitCount elemet
    of the querytree (a Node *) isn't NULL what it is by default.

    When a LIMIT is given, the optimizer could assume that  first
    rows  is  wanted (even if the limit is ALL maybe - but I have
    to think about this some more). And this assumption might let
    it  decide  to use an index to resolve an ORDER BY even if no
    qualification was given.

    Telling the optimizer that first  rows  wanted  in  a  cursor
    operation would read

        DECLARE CURSOR c FOR SELECT * FROM mytab ORDER BY a LIMIT ALL;


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

pgsql-hackers by date:

Previous
From: Andreas Zeugswetter
Date:
Subject: AW: [HACKERS] SELECT ... LIMIT (trial implementation)
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: inet/cidr/bind