I wrote:
> So I'm now thinking you weren't that far wrong to be looking at
> hashability of the top-level qual operator. What is missing is
> that you have to restrict candidate cache keys to be the *direct*
> arguments of such an operator. Looking any further down in the
> expression introduces untenable assumptions.
Hmm ... I think that actually, a correct statement of the semantic
restriction is
To be eligible for memoization, the inside of a join can use the
passed-in parameters *only* as direct arguments of hashable equality
operators.
In order to exploit RestrictInfo-based caching, you could make the
further restriction that all such equality operators appear at the
top level of RestrictInfo clauses. But that's not semantically
necessary.
As an example, assuming p1 and p2 are the path parameters,
(p1 = x) xor (p2 = y)
is semantically safe to memoize, despite the upper-level xor
operator. But the example we started with, with a parameter
used as an argument of jsonb_exists, is not safe to memoize
because we have no grounds to suppose that two hash-equal values
will act the same in jsonb_exists.
regards, tom lane
