| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Show hashed SAOP decision in EXPLAIN |
| Date: | 2026-06-09 09:51:07 |
| Message-ID: | e7914157-0311-4a81-ac62-88ee9cbb8c2d@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
This is a follow-up to [1].
EXPLAIN already shows when an operation relies on a hash table — hashed SubPlan,
HashAggregate, HashSetOp — which helps users understand a plan's performance. A
hashed ScalarArrayOpExpr is the exception: it deparses exactly like the linear
form, so EXPLAIN gives no indication of which strategy the executor will use.
That is worth surfacing. The array can be long and the comparison runs as a scan
filter, so whether the executor builds a hash table or falls back to a linear
search has a real cost. The attached patch marks the hashed case.
Making the decision visible also makes it testable, so the patch adds
regression tests that fill the test gap left by commit 06e94eccfd9, which taught
the planner to re-check hashability for container-type equality but added no
tests of its own.
[1] https://www.postgresql.org/message-id/570738.1780934420%40sss.pgh.pa.us
--
regards, Andrei Lepikhov,
pgEdge
| Attachment | Content-Type | Size |
|---|---|---|
| v0-0001-Show-hashed-ScalarArrayOpExpr-decision-in-EXPLAIN.patch | text/plain | 10.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adam Lee | 2026-06-09 09:55:04 | [PATCH] Avoid orphaning buffers when a relation's file is missing |
| Previous Message | solai v | 2026-06-09 09:35:03 | Re: Logging parallel worker draught |