Re: A performance issue with Memoize

David Rowley <dgrowleyml@gmail.com>

From: David Rowley <dgrowleyml@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-01-26T07:54:45Z
Lists: pgsql-hackers
On Fri, 26 Jan 2024 at 19:03, Richard Guo <guofenglinux@gmail.com> wrote:
> At first I wondered if we should assume that the same param expr must
> have the same equality operator. If not, we should also check the
> operator to tell if the cache key is a duplicate, like
>
> -           if (!list_member(*param_exprs, expr))
> +           if (!list_member(*param_exprs, expr) ||
> +               !list_member_oid(*operators, hasheqoperator))

hmm, if that were the case you wouldn't do it that way. You'd need to
forboth() and look for an item in both lists matching the search.

> But after looking at how rinfo->left_hasheqoperator/right_hasheqoperator
> is set, it seems we can assume that: the operator is from the type cache
> entry which is fetched according to the expr datatype.

Yip.

> So I think the patch makes sense.  +1.

Thanks for reviewing. I've pushed the patch.

David



Commits

  1. Attempt to fix newly added Memoize regression test

  2. Compare varnullingrels too in assign_param_for_var().

  3. De-dupicate Memoize cache keys

  4. Improve NestLoopParam generation for lateral subqueries

  5. Avoid sharing PARAM_EXEC slots between different levels of NestLoop.