Re: jsonb crash

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: jsonb crash
Дата
Msg-id 3004308.1632952496@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: jsonb crash  (David Rowley <dgrowley@gmail.com>)
Ответы Re: jsonb crash  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: jsonb crash  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
David Rowley <dgrowley@gmail.com> writes:
> On Thu, 30 Sept 2021 at 10:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm still confused.  AFAICS, the top-level operator of the qual clause has
>> exactly nada to do with the cache keys, as this example makes plain.

> You're right that it does not. The lateral join condition could be
> anything.

Actually, the more I look at this the more unhappy I get, because
it's becoming clear that you have made unfounded semantic
assumptions.  The hash functions generally only promise that they
will distinguish values that are distinguishable by the associated
equality operator.  We have plenty of data types in which that does
not map to bitwise equality ... you need not look further than
float8 for an example.  And in turn, that means that there are lots
of functions/operators that *can* distinguish hash-equal values.
The fact that you're willing to treat this example as cacheable
means that memoize will fail on such clauses.

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.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: jsonb crash
Следующее
От: Michail Nikolaev
Дата:
Сообщение: Re: [PATCH] Full support for index LP_DEAD hint bits on standby