Re: apply_scanjoin_target_to_paths and partitionwise join

On Sat, Nov 22, 2025 at 7:06 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I'm pretty happy with the resulting patch, and plan to commit it (only
> to master) if nobody has any complaints. Please let me know if you
> have complaints.

The changes to the test cases look good to me.

Regarding the changes to apply_scanjoin_target_to_paths():

- if (rel_is_partitioned)
+ if (rel_is_partitioned && IS_SIMPLE_REL(rel))
rel->pathlist = NIL;

As I understand it, we want to drop the existing Append paths for a
partitioned table, because in apply_scanjoin_target_to_paths() we will
re-generate brand-new Append paths after applying the scan/join target
to all partitions. This ensures that the scan/join target is computed
below the Append rather than above it. This may help save a separate
Result node, and it also is important for partitionwise aggregate.

IIUC, the specific change in this patch is to drop the existing Append
paths only for partitioned base relations. This means that, for a
partitioned join relation, the existing Append paths are retained.
Therefore, for each Append path of a partitioned join relation, we
will end up with two paths: one where the scan/join target is computed
above the Append, and one where it is computed below the Append.

I kind of wonder whether having these two distinct Append paths for
partitioned join relations could lead to the problems described in the
code comments: redundant path generation work, and cross-platform plan
variations.

- Richard