Re: updated SORT/LIMIT patch

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Updated patch against cvs update in case it makes applying easier.
>
> Applied with revisions --- notably, I avoided adding any overhead to
> HEAPCOMPARE() by the expedient of reversing the logical sort order
> before heapify'ing. We couldn't have done that before the NULLS_FIRST
> patch went in, but now it's trivial to make the sort order reverse
> fully.

Hum. The major change I see is the bit related to rescans where you made it
resort if the bound had changed. But surely the only way the bound can change
is if it's a parameter, and if there is a parameter then surely the executor
must be doing more than just a plain rescan? The sort key could have changed
if it depends on the parameter.

What does the executor do differently in the case of a subplan with a
parameter that makes it re-execute the plan from scratch and not just do a
simple rescan?

> Since you didn't include any documentation patch for the
> optimize_bounded_sort GUC variable, I assumed it was meant only for
> debugging and hid it behind #ifdef DEBUG_BOUNDED_SORT.

Sure, I originally had it #ifdef'd on TRACE_SORT but took it out for reasons
that I don't recall.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com