Re: jsonb crash

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowley(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, David Rowley <drowley(at)postgresql(dot)org>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: jsonb crash
Date: 2021-09-29 22:20:56
Message-ID: 3005541.1632954056@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-09-29 22:32:09 Re: Enabling deduplication with system catalog indexes
Previous Message Michail Nikolaev 2021-09-29 22:09:23 Re: [PATCH] Full support for index LP_DEAD hint bits on standby