"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
