I wrote:
> I think this must be a memoize bug. AFAICS, nowhere in this query
> can we be processing a non-null JSONB value, so what are we doing
> in jsonb_hash? Something down-stack must have lost the information
> that the Datum is actually null.
After further inspection, "what are we doing in jsonb_hash?" is
indeed a relevant question, but it seems like it's a type mismatch
not a nullness issue. EXPLAIN VERBOSE shows
-> Memoize (cost=0.01..1.96 rows=1 width=4)
Output: subq_0.c5
Cache Key: ref_0.c, ref_0.a
-> Subquery Scan on subq_0 (cost=0.00..1.95 rows=1 width=4)
Output: subq_0.c5
Filter: (CASE WHEN (subq_0.c5 < 2) THEN NULL::jsonb ELSE
NULL::jsonb END ? ref_0.c)
-> Limit (cost=0.00..0.78 rows=78 width=4)
Output: (ref_0.a)
-> Function Scan on pg_catalog.generate_series sample_0
(cost=0.00..3.00 rows=300 width=4)
Output: ref_0.a
Function Call: generate_series(1, 300)
so unless the "Cache Key" output is a complete lie, the cache key
types we should be concerned with are text and integer. The Datum
that's being passed to jsonb_hash looks suspiciously like it is a
text value '0000', too, which matches the "c" value from the first
row of pagg_tab_ml. I now think some part of Memoize is looking in
completely the wrong place to discover the cache key datatypes.
regards, tom lane
