From: | jwieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | Inoue(at)tpf(dot)co(dot)jp (Hiroshi Inoue) |
Cc: | jwieck(at)debis(dot)com, pgsql-hackers(at)postgreSQL(dot)org, maillist(at)candle(dot)pha(dot)pa(dot)us |
Subject: | Re: [HACKERS] What about LIMIT in SELECT ? |
Date: | 1998-10-19 10:30:52 |
Message-ID: | m0zVCaT-000EBPC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-10-19 10:52:01 | Re: [HACKERS] Re: inet/cidr/bind |
Previous Message | Andreas Zeugswetter | 1998-10-19 10:19:56 | AW: [HACKERS] SELECT ... LIMIT (trial implementation) |