| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | Tender Wang <tndrwang(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: remove_useless_joins vs. bug #19560 |
| Date: | 2026-09-13 17:32:15 |
| Message-ID: | 9752.1789320735@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> I think a straightforward way to achieve that is that in
> subquery_planner, we walk the whole query tree and preprocess all of
> the current level's PHVs that got pushed down into subqueries, up
> front before anything consumes them. Then the subquery's own
> processing can just ignore upper-level PHVs. eval_const_expressions
> returns them as-is, and flatten_join_alias_vars stops descending into
> them.
> This still keeps the copies around rather than relying solely on the
> PlaceHolderInfo, but since they'd be folded the same way as the
> owning-level version, maybe it still gets the consistency we want to
> have.
Yeah. Since we need to back-patch this, let's not get too aggressive
about optimizing such cases. Maybe later we could look into avoiding
the duplicate processing in a master-only patch.
> One problem with this is that we walk the whole query tree to find
> those copies, which costs some planning cycles. We could gate it on
> root->glob->lastPHId != 0 to skip queries with no PHVs at all, but
> beyond that I don't have a good way to narrow it down.
I see you did put in that gate, and again I think that's enough for
now. We could conceivably try to track which query levels own PHVs,
and then only recurse down from those levels. But I fear that'd be
about as hard to keep straight as hasSubLinks, which has caused us
plenty of heartburn in the past. Again, let's leave such optimization
for another day.
In short, LGTM, please push.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Nestorov | 2026-09-13 17:43:16 | Re: [PATCH] btree_gist: add cross-type integer operator support for GiST |
| Previous Message | Noah Misch | 2026-09-13 17:21:23 | Re: Two issues leading to discrepancies in FSM data on the standby server |