Hi Tender,
thanks for having a look here again.
On 2026-07-13 3:44 PM, Tender Wang wrote:
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.
The same should be true for union statements, plain inheritance and
pretty much anything, which creates an append.
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.
Thank you, reviews are valuable!
Regards
Arne
