| 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
| 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 |