Re: BUG #19362: Extremely log processing of jsonb_path_exists_opr

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Andrey Rachitskiy <therealgofman(at)mail(dot)ru>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, dhyan(at)nataraj(dot)su
Subject: Re: BUG #19362: Extremely log processing of jsonb_path_exists_opr
Date: 2026-05-01 12:20:00
Message-ID: DD2A3250-D456-4871-A245-9E851BC59B66@yandex-team.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On 24 Dec 2025, at 00:02, Andrey Rachitskiy <therealgofman(at)mail(dot)ru> wrote:
>
> Strict mode exhibits similar behavior to LAX mode, consuming significant CPU resources.
>

Hi!

Examples that you show represent an opportunity for a performance optimization,
but hardly constitute a bug.

But I think to showcase this opportunity it would be good to demonstrate more
realistic query.

I cannot imagine end user wanting a query like

SELECT data @? '$.**.**.**.**.*' FROM test_json;

or

select
'[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[0]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]'::jsonb
@? '++$.**.**.**.**.*'::jsonpath;

Please, construct a more realistic example of what user might want, but not get
in reasonable time.

FWIW, I've asked LLM and it thinks that optimization is worth doing:

<LLM output>

The query pattern $.**[*] ? (@ == "x") or $.**.* ? (@ == "x") is something a
developer might write when searching for values at any depth in JSON data that
contains arrays (task lists, comment threads, nested categories). The intent
is clear: "find this value anywhere in the structure, including inside arrays."
The performance degradation from O(N) to O(N²) occurs at moderate nesting
depths that can appear in real data — 50-level comment threads, 30-level
org charts, etc.
More importantly, if the application passes user-provided jsonpath expressions
to @?, the $.**.**.**.**.* pattern becomes a DoS vector requiring no special
privileges — only the ability to submit a query.
A meaningful optimization would be to collapse consecutive .** operators
(.** {a,b} .** {c,d} → .** {a+c, b+d}) at parse or execution time, which
would make $.**.**.**.**.* behave identically to $.**.* in O(N²) time
rather than O(N⁵).

</LLM output>

But I think it's a matter for pgsql-hackers, not pgsql-bugs.

Best regards, Andrey Borodin.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Zhongpu Chen 2026-05-01 13:59:18 Character with byte sequence 0xa2 0xa3 in encoding "EUC_CN" has no equivalent in encoding "UTF8"
Previous Message Richard Guo 2026-05-01 01:23:28 Re: BUG #19418: SQL/JSON JSON_VALUE() does not conform to ISO/IEC 9075-2:2023(E) 6.34 <JSON value constructor>