>> 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