On Thu, 30 Sept 2021 at 07:55, Jaime Casanova
<jcasanov@systemguards.com.ec> wrote:
> """
> select
> 75 as c1
> from
> public.pagg_tab_ml as ref_0,
> lateral (select
> ref_0.a as c5
> from generate_series(1, 300) as sample_0
> fetch first 78 rows only
> ) as subq_0
> where case when (subq_0.c5 < 2)
> then cast(null as jsonb)
> else cast(null as jsonb)
> end ? ref_0.c
> """
I've attached 2 patches that aim to fix this bug. One for master and
one for pg14. Unfortunately, for pg14, RestrictInfo lacks a field to
store the righthand type's hash equality operator. I don't think it's
going to be possible as [1] shows me that there's at least one project
outside of core that does makeNode(RestrictInfo). The next best thing
I can think to do for pg14 is just to limit Memoization for
parameterizations where the RestrictInfo has the same types on the
left and right of an OpExpr. For pg14, the above query just does not
use Memoize anymore.
In theory, since this field is just caching the hash equality
operator, it might be possible to look up the hash equality function
each time when the left and right types don't match and we need to
know the hash equality operator of the right type. That'll probably
not be a super common case, but I wouldn't go as far as to say that
it'll be rare. I'd be a bit worried about the additional planning
time if we went that route. The extra lookup would have to be done
during the join search, so could happen thousands of times given a bit
more than a handful of tables in the join search.
For master, we can just add a new field to RestrictInfo. The master
version of the patch does that.
Does anyone have any thoughts on the proposed fixes?
David
[1] https://codesearch.debian.net/search?q=makeNode%28RestrictInfo%29&literal=1
