On Mon, Apr 15, 2024 at 9:00 AM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > > Here's patch with > [..] > Adding to the next commitfest but better to consider this for the next set of minor releases.
(all due to "regression tests pass" failures) [...]
So with the patch that SQL does not use partitionwise join as it finds it more optimal to stick to a plan with cost of "1.10..2.21" instead of "1.11..2.22" (w/ partition_join), nitpicking but still a failure technically. Perhaps it could be even removed? (it's pretty close to noise?).
The test was added by 6b94e7a6da2f1c6df1a42efe64251f32a444d174 and later modified by 3c569049b7b502bb4952483d19ce622ff0af5fd6. The modification just avoided eliminating the join, so that change can be ignored. 6b94e7a6da2f1c6df1a42efe64251f32a444d174 added the tests to test fractional paths being considered when creating ordered append paths. Reading the commit message, I was expecting a test which did not use a join as well and also which used inheritance. But it seems that the queries added by that commit, test all the required scenarios and hence we see two queries involving join between partitioned tables. As the comment there says the intention is to verify index only scans and not exactly partitionwise join. So just fixing the expected output of one query looks fine. The other query will test partitionwise join and fractional paths anyway. I am including Tomas, Arne and Zhihong, who worked on the first commit, to comment on expected output changes.
I will create patches for the back-branches once the patch for master is in a committable state.