On Wed, Dec 3, 2025 at 9:53 PM Richard Guo <[email protected]> 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
