Thread: Subselect and limit/order?

Just wondering why subselect expressions can not have a limit/order clause,
eg.
   select id,(select id from tbl where id > ? order by id limit 1) as nextid    from tbl where id = ?;

is quite usefull.

It can obviously be done in two select statements, but I was just wondering
if it's an oversight or a planner problem?



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

At 11:46 7/08/00 -0400, Tom Lane wrote:
>Philip Warner <pjw@rhyme.com.au> writes:
>> Just wondering why subselect expressions can not have a limit/order clause,
>
>We could ignore the spec and implement this as an extension, but I'd
>want to see some fairly compelling arguments why it's a good idea.
>(In other words, why do you know better than the designers of SQL?)

Well, it's not *just* me. Both Dec/RDB and SQL/Server implement ORDER BY in
subqueries. SQL/Server insists on a limit statement in this case, whereas
Dec/Rdb just dies if more than one row is returned.

It is a very useful thing when you are scanning though sequential records
that are time based, or have ID's that have 'holes' in the sequence. eg. in
the case of time-based data, you can derive durations.

But it can be done by writing a plpgsql function, so it's not a big issue. 


>> It can obviously be done in two select statements, but I was just wondering
>> if it's an oversight or a planner problem?
>
>I'd say mostly an executor problem, actually.  Nobody's figured out
>where the executor would need to be hacked to support tuple-limits
>applied elsewhere than the top level of a select.

Wouldn't is also have a fair impact on the planner? Or does it always
assume that subselects only return one row?



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

At 11:46 7/08/00 -0400, Tom Lane wrote:
>
>I'd say mostly an executor problem, actually.  Nobody's figured out
>where the executor would need to be hacked to support tuple-limits
>applied elsewhere than the top level of a select.

Shouldn't the optimizer be able to get some benefit (in colun select
expressions at least) by being able to do an implied 'limit 2'?





----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/