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
