Re: [PATCH]Fix planner's strictness check for JsonExpr

From: Ethan Tran <ethantran(at)quwin(dot)dev>
To: Keyerror Smart <smartkeyerror(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH]Fix planner's strictness check for JsonExpr
Date: 2026-11-05 18:04:18
Message-ID: 827E9240-841E-4DEB-B299-5DF7D3268215@quwin.dev
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Zhenglong,
> Could you check which ON ERROR behavior your 35 ms -> 196 ms benchmark
> used? If it used the default, v3 should keep it inlined.

Yes, the benchmark used default NULL ON EMPTY/ON ERROR.
On my rerun, v3 now keeps it inlined without any performance issues.
> So v3 treats a JsonExpr as strict only if
> it has no PASSING arguments and both behaviors are NULL or ERROR

Would UNKNOWN ON ERROR be worth including, since it is another NULL
fallback? Constant NULL defaults also seem to fit the NULL-or-error rule,
but these could be left for a follow-up.
> I think that's an acceptable price for a rule that is easy to verify and
> back-patch. If it matters, the more precise check with a plan dependency
> could be done separately on master.

I agree, keeping the back-patch straightforward and leaving other optimization rules
for a separate follow-up change seems like the best option here.

Thanks,
Ethan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Narek Galstyan 2026-11-05 18:05:42 Fix btree_gist index corruption on bit and varbit types
Previous Message Lukas Fittl 2026-11-05 18:02:13 Re: Report buffer access strategies in EXPLAIN