On Wed, 22 Oct 2025 at 21:48, Emmanuel Touzery
<emmanuel.touzery@plandela.si> wrote:
> I can confirm that seting jit_tuple_deforming to off is enough to fix the issue.
Thanks for checking that.
It does look like something weird is going on with the JIT deforming
code. I was playing around with the attached patch applied to look at
the tuple data. Rather surprisingly, the Datum value for negative ints
isn't the same for JIT deform vs normal deform.
Here's an example:
test=# set jit_above_cost=0;
SET
test=# create table a (a int);
CREATE TABLE
test=# insert into a values(-353400);
INSERT 0 1
test=# set jit=1;
SET
test=# explain analyze select * from a where a < 0;
NOTICE: scan tuple = (a) (-353400) (4294613896)
test=# set jit=0;
SET
test=# explain analyze select * from a where a < 0;
NOTICE: scan tuple = (a) (-353400) (18446744073709198216)
The format there is (<column>) (<logical value>) (<raw datum value>)
The lower 32 bits of these numbers are the same:
0000000000000000000000000000000011111111111110101001101110001000
1111111111111111111111111111111111111111111110101001101110001000
It's the upper 32 bits that are all 1s for no JIT and all zeros for JIT.
The reason this is causing Memoize indigestion is because when in
binary mode, the cache lookup is done with datum_image_hash() and
datum_image_eq(). I didn't check exactly, but I suspect that the value
we get when deforming the cache key's MinimalTuple has the Datum with
the non JIT representation.
To figure out why this is happening requires caffeination and staring
at llvmjit_deform.c for a long time. I suspect whatever is in there
that's meant to do what fetch_att() does isn't doing it the same way.
David
