On Thu, 30 Sept 2021 at 07:55, Jaime Casanova <jcasa...@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
memoize_type_bug_master.patch
Description: Binary data
memoize_type_bug_pg14.patch
Description: Binary data
