Hi, I've pushed the second part of this patch series, adding incremental sort to additional places in the planner. As explained in the commit message (and somewhere in this thread) we've decided to only update some of the places that require sorted input (and do create_sort). This might be overly cautious, I expect we'll add it to more places in the future.
As for the remaining part tweaking add_partial_path to also consider startup cost (a bit confusingly 0001 - 0003 in the v54 patchset), I've decided not to push it now and leave it for v14. The add_partial_path change is simple, but I came to the conclusion that the "precheck" function should be modified to follow the same logic - it would be a bit strange if add_partial_path_precheck considered only total cost and add_partial_path considered both startup and total cost. It would not matter for most places because the add_partial_path_precheck is ony used in join planning, but it's still strange. I could have modified the add_partial_path_precheck too, but looking at add_path_precheck we'd probably need to compute required_outer so that we only compare startup_cost when really useful. Or we might simply consider startup_cost every time and leave that up to add_partial_path, but then that would be another difference in behavior. That seems like way too much stuff to rework on the last day of the last commitfest. It does mean we'll fail to generate the cheapest plan in some cases (e.g. with LIMIT, there's an example in [1]) but that's a pre-existing condition, not something introduced by incremental sort. regards [1] https://www.postgresql.org/message-id/20190720132244.3vgg2uynfpxh3me5%40development -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
