Re: [HACKERS] What about LIMIT in SELECT ?

>>       postgres just because of lacking LIMIT. Tatsuo posted a patch
>>       for set query_limit to 'num', I just tested it and seems it
>>       works fine. Now, we need only possibility to specify offset,
>>       say
>>          set query_limit to 'offset,num'
>>       ( Tatsuo, How difficult to do this ?)
>>       and LIMIT problem will ne gone.
>
>    Think you haven't read my posting completely. Even  with  the
>    executor  limit,  the  complete scan into the sort is done by
>    the backend.  You need to specify ORDER BY to  get  the  same
>    list  again  (without  the  offset  doesn't  make sense). But
>    currently, ORDER BY forces a sort node into the query plan.

I think we have understanded your point. set query_limit is just a
easy alternative of using cursor and fetch.

>    I  haven't  looked  at  Tatsuo's  patch  very well. But if it
>    limits the amount of data going into the sort (on ORDER  BY),
>    it  will  break it! The requested ordering could be different
>    from what the choosen index might return. The used  index  is
>    choosen by the planner upon the qualifications given, not the
>    ordering wanted.

I think it limits the final result. When query_limit is set,
the arg "numberTuples" of ExecutePlan() is set to it instead of 0
(this means no limit).

Talking about "offset," it shouldn't be very difficult. I guess all we
have to do is adding a new arg "offset" to ExecutePlan() then making
obvious modifications. (and of course we have to modify set
query_limit syntax but it's trivial)

However, before going ahead, I would like to ask other hackers about
this direction. This might be convenient for some users, but still the
essential performance issue would remain. In another word, this is a
short-term solution not a intrinsic one, IMHO.
--
Tatsuo Ishii
t-ishii@sra.co.jp