From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A performance issue with Memoize |
Date: | 2024-01-25 17:22:59 |
Message-ID: | 412552.1706203379@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I'd feel better about doing it your way if Tom could comment on if
> there was a reason he put the function calls that way around in
> 5ebaaa494.
Apologies for not having noticed this thread before. I'm taking
a look at it now. However, while sniffing around this I found
what seems like an oversight in paramassign.c's
assign_param_for_var(): it says it should compare all the same
fields as _equalVar except for varlevelsup, but it's failing to
compare varnullingrels. Is that a bug? It's conceivable that
it's not possible to get here with varnullingrels different and
all else the same, but I don't feel good about that proposition.
I tried adding
@@ -91,7 +91,10 @@ assign_param_for_var(PlannerInfo *root, Var *var)
pvar->vartype == var->vartype &&
pvar->vartypmod == var->vartypmod &&
pvar->varcollid == var->varcollid)
+ {
+ Assert(bms_equal(pvar->varnullingrels, var->varnullingrels));
return pitem->paramId;
+ }
}
}
This triggers no failures in the regression tests, but we know
how little that proves.
Anyway, that's just a side observation unrelated to the problem
at hand. More later.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-01-25 17:25:46 | Re: Emit fewer vacuum records by reaping removable tuples during pruning |
Previous Message | Sergey Prokhorenko | 2024-01-25 17:04:05 | Re: UUID v7 |