On 6/14/24 19:00, Alexander Korotkov wrote:
This patch could use some polishing, but I'd like to first hear some
feedback on general design.
Thanks for your time and efforts. I have skimmed through the code—there
is a minor fix in the attachment.
First and foremost, I think this approach can survive.
But generally, I'm not happy with manipulations over a restrictinfo clause:
1. While doing that, we should remember the fields of the RestrictInfo
clause. It may need to be changed, too, or it can require such a change
in the future if someone adds new logic.
2. We should remember the link to the RestrictInfo: see how the caller
of the distribute_restrictinfo_to_rels routine manipulates its fields
right after the distribution.
3. Remember caches and cached decisions inside the RestrictInfo
structure: replacing the clause should we change these fields too?
These were the key reasons why we shifted the code to the earlier stages
in the previous incarnation. So, going this way we should recheck all
the fields of this structure and analyse how the transformation can
[potentially] affect their values.
--
regards,
Andrei Lepikhov
Postgres Professional
diff --git a/src/backend/optimizer/plan/initsplan.c b/src/backend/optimizer/plan/initsplan.c
index 0022535318..3b3249b075 100644
--- a/src/backend/optimizer/plan/initsplan.c
+++ b/src/backend/optimizer/plan/initsplan.c
@@ -2981,7 +2981,15 @@ add_base_clause_to_rel(PlannerInfo *root, Index relid,
if (list_length(orExpr->args) >= 2)
{
- orExpr->args = transform_or_to_any(root, orExpr->args);
+ List *args = transform_or_to_any(root, orExpr->args);
+
+ if (list_length(args) > 1)
+ orExpr->args = args;
+ else
+ {
+ restrictinfo->orclause = NULL;
+ restrictinfo->clause = (Expr*)((RestrictInfo *)linitial(args))->clause;
+ }
}
}
