Arne Roland <[email protected]> 于2026年7月13日周一 18:24写道： > > Hi Richard, > > thank you for your great work with the optimizer! > > I just stumbled and by accident landed on your commit 9a60f295bcb (and > then looked up the discussion > https://www.postgresql.org/message-id/flat/CALzhyqwryL2QywgO03VQr_237Sq3MEVgTTT2_A9G3nGT5-SRZg%40mail.gmail.com). > I am under the impression we need to extend the same fix for or clauses > descending into the orclause sub-RestrictInfos. > > This is the simplified minimal test case, that is failing for me: > > CREATE TABLE a (id int PRIMARY KEY, b_id int); > CREATE TABLE uniq (id int PRIMARY KEY); > CREATE TABLE parted_b (id int PRIMARY KEY) PARTITION BY RANGE (id); > CREATE TABLE parted_b1 PARTITION OF parted_b FOR VALUES FROM (0) TO (10); > > SELECT 1 FROM a, (SELECT t1.id FROM parted_b t1 LEFT JOIN uniq t2 ON > t1.id = t2.id) s > WHERE (s.id = 1 AND a.id = 2) OR (s.id = 3 AND a.id = 4) GROUP BY (); >
Yeah, the last fix can't cover this case, because the otherrel->baserestrictinfo is NIL when trying to remove outerjoin rel from phv. The the otherrel->baserestrictinfo would be assigned when calling extract_restriction_or_clauses() in query_planner(). But in extract_restriction_or_clauses(), we had no way to make the thing right. > My idea would be to put a bitmapset into remove_rel_from_query with the > seen ones and recurse removing it from the rinfo. I attached a sketch of > my idea. But maybe our have a better one. It seems that we have to process otherrel's baserestrictinfo and joininfo if the query involves a partition table. If we ignore one of them in add_other_rels_to_query(), the rel that was removed is brought back to the child rel. Then the crash would happen. I took a quick look at this patch. It seems workable. -- Thanks, Tender Wang
