Re: A performance issue with Memoize
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Rowley <dgrowleyml@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-01-26T05:38:53Z
Lists: pgsql-hackers
On Fri, Jan 26, 2024 at 1:22 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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;
> + }
> }
> }
Yeah, I think it should be safe to assert that the varnullingrels is
equal here. The Var is supposed to be an upper-level Var, and two same
such Vars should not have different varnullingrels at this point,
although the varnullingrels might be adjusted later in
identify_current_nestloop_params according to which form of identity 3
we end up applying.
Thanks
Richard
Commits
-
Attempt to fix newly added Memoize regression test
- a3a836fb5e51 17.0 landed
-
Compare varnullingrels too in assign_param_for_var().
- 807369d80384 16.2 landed
- 5e444a2526cc 17.0 landed
-
De-dupicate Memoize cache keys
- bc397e5cdb31 17.0 landed
-
Improve NestLoopParam generation for lateral subqueries
- 2cca95e17546 17.0 landed
-
Avoid sharing PARAM_EXEC slots between different levels of NestLoop.
- 1db5667bac63 12.0 cited