Re: GIN jsonpath scans miss rows when methods follow a predicate

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: GIN jsonpath scans miss rows when methods follow a predicate
Date: 2026-10-14 08:27:55
Message-ID: CAHGQGwHO0ggM78cpgAxQ4KfxGFxObsDZpY3er_Qs8ZQSYG7wnQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 14, 2026 at 10:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> This is related to one of the bugs I fixed in b28a2b2bf, but I think
> it's different. I fear your patch might be too sweeping though ---
> are you sure it doesn't reject cases that would be valid? I'd prefer
> to inject the no-nextPos test on a per-node-type basis.

Yes, you're right. Seems we can safely extract an index condition if
the combined effect of the items following a predicate cannot turn false
or unknown predicate result into true. For example,
"($ == 1).string().lower().boolean()" can still use its index condition.

So I've updated the patch to check the entire chain of items following
a predicate. It allows chains that are safe as a whole and conservatively
skips extraction otherwise.

I've identified 13 such item types so far, but of course I may have
missed some. Thoughts?

Regards,

--
Fujii Masao

Attachment Content-Type Size
v2-0001-Fix-GIN-jsonpath-index-conditions-for-predicates-.patch application/octet-stream 12.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Bohyun Lee 2026-10-14 08:04:53 Re: pg_upgrade fails with a config-only datadir and no --new-bindir