Re: apply_scanjoin_target_to_paths and partitionwise join

On Wed, Dec 3, 2025 at 9:53 PM Richard Guo <guofenglinux@gmail.com> wrote:
> Fair point.  I had envisioned a separate planning step involving a new
> RelOptInfo, where we would re-add paths from the scan/join RelOptInfo
> after applying the target, explicitly skipping Append paths for
> partitioned tables.  But I admit that I am unsure if this addresses
> any real problems, so the effort might not be justified.  I agree that
> maybe we should just go ahead with your current patch and see what
> happens.

I believe that I tried this at the time, and found that the cost was
uncomfortably large for very simple queries. I don't remember whether
I tried creating a separate RelOptInfo or something slightly simpler,
like a new list of paths without a full RelOptInfo.

> I suspect the same.  IMHO, apply_scanjoin_target_to_paths is quite
> brute-force and modifies planner structures in ways we generally
> should avoid (no offense intended to the original author of this
> function).  I agree that the correct long-term solution is to generate
> the expected target from the start, which would eliminate the need for
> apply_scanjoin_target_to_paths entirely.

Agreed.

--
Robert Haas
EDB: http://www.enterprisedb.com