On Wed, Jan 31, 2024 at 1:33 PM Alexander Kuzmenkov <akuzmen...@timescale.com> wrote: > I'd be happy to see this backpatched. What kind of regressions are we > worried about? I'd say partition-wise sort + merge should be faster > than append + sort for reasonably sized tables. That's basically what > tuplesort does inside. Moreso, this can enable index scans on > partitions, which is an even better plan.
To put it another way, this change enables our usual cost model for MergeAppend to work correctly in the presence of filters. I think we can consider this model to be reasonably correct, and we don't currently have major problems with MergeAppend being chosen instead of Sort + Append in cases where it's suboptimal, right? So applying it properly in case with filters is not likely to introduce problems.
