RE: [HACKERS] What about LIMIT in SELECT ?

Hi all.
I didn't follow all the posts about this thread.
So this post may be out of center.

I think current PostgreSQL lacks the concern to the response to get first
rows quickly.
For example,queries with ORDER BY clause necessarily include sort steps
and process all target rows to get first rows only.
So I modified my code for ORDER BY cases and use on trial.
I don't understand PostgreSQL sources,so my code is not complete.

I modified my code for the following 2 cases.

1.In many cases the following query uses index scan.
SELECT * from ... where key > ...; (where (key) is an index)
If so,we can omit sort steps from the access plan for the following
query.
SELECT * from ... where key > ... order by key;

Currently cursors without sort steps may be sensitive diffrent from
cursors with sort steps. But no one mind it.

2.In many cases the following query uses index scan same as case 1.
SELECT * from ... where key < ...;(where (key) is an index)
If so and if we scan the index backward,we can omit sort steps from
the access plan for the following query.
SELECT * from ... where key < ... order by key desc;

To achive this(backward scan),I used hidden(provided for the future ?)code
that is never executed and is not necessarily correct.

In the following cases I didn't modify my code to use index scan,
because I couldn't formulate how to tell PostgreSQL optimizer whether
the response to get first rows is needed or the throughput to process
sufficiently many target rows is needed.

3.The access plan made by current PostgreSQL optimizer for a query with
ORDER BY clause doesn't include index scan.

I thought the use of Tatsuo's QUERY_LIMIT to decide that the responce
is needed. It is sufficient but not necessary ?
In Oracle the hints FIRST_ROWS,ALL_ROWS are used.

Thanks.

Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp