"Tom Lane" <[EMAIL PROTECTED]> writes:

> Gregory Stark <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to