Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix missed checks for hashability of container-type equality.

  1. Show hashed SAOP decision in EXPLAIN

    Andrei Lepikhov <lepihov@gmail.com> — 2026-06-09T09:51:07Z

    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

  2. Re: Show hashed SAOP decision in EXPLAIN

    Nishant Sharma <nishant.sharma@enterprisedb.com> — 2026-06-19T13:28:09Z

    Thanks for the v0 patch set!

The topic is new to me. I thought I would review it to see if I could learn
something.

Code changes are small, simple and clean.

Here are my comments:
1. Should we add a test case that confirms the comment: "this never appears
in deparsed views, rules, or other stored expressions". Also, what about
multirange tests?
2. I see that the word "hashed" is added for all valid hashfuncid in the
plan, which implies that hash is used instead of array for those cases. If
this is being done, why not explicitly include "linear" or "array" for
non-valid hashfuncid instead of keeping "" empty, given that the goal is to
provide more information? I saw too many differences in existing tests and
also in the upgrade test in make check world. So, I think that's not a good
idea.
3. Ran make check world, it looked clean for the v0 patch.


Thanks,
Nishant Sharma,
EDB, Pune.
https://www.enterprisedb.com/

  3. Re: Show hashed SAOP decision in EXPLAIN

    Andrei Lepikhov <lepihov@gmail.com> — 2026-06-22T09:14:24Z

    On 19/06/2026 15:28, Nishant Sharma wrote:
> Thanks for the v0 patch set!
> 
> The topic is new to me. I thought I would review it to see if I could learn
> something.
> 
> Code changes are small, simple and clean.

Thanks for your interest!

> 
> Here are my comments:
> 1. Should we add a test case that confirms the comment: "this never appears in
> deparsed views, rules, or other stored expressions". Also, what about multirange
> tests?

Ok, done.

> 2. I see that the word "hashed" is added for all valid hashfuncid in the plan,
> which implies that hash is used instead of array for those cases. If this is
> being done, why not explicitly include "linear" or "array" for non-valid
> hashfuncid instead of keeping "" empty, given that the goal is to provide more
> information? I saw too many differences in existing tests and also in the
> upgrade test in make check world. So, I think that's not a good idea.
Here, we just follow the hashed SubPlan approach. I think we don't need anything
else here.

-- 
regards, Andrei Lepikhov,
pgEdge

  4. Re: Show hashed SAOP decision in EXPLAIN

    Nishant Sharma <nishant.sharma@enterprisedb.com> — 2026-06-25T10:37:44Z

    v1 looks good based on my understanding.

What about back-porting? If this is for PG20, I checked the v1 patch up to
PG15.

From MASTER to PG16 make check world passed, but it is failing for PG15.


Thanks,
Nishant Sharma.
EDB, Pune.
https://www.enterprisedb.com/

  5. Re: Show hashed SAOP decision in EXPLAIN

    Andrei Lepikhov <lepihov@gmail.com> — 2026-06-25T10:41:36Z

    On 25/06/2026 12:37, Nishant Sharma wrote:
> v1 looks good based on my understanding.
> 
> What about back-porting? If this is for PG20, I checked the v1 patch up to PG15.
> 
> From MASTER to PG16 make check world passed, but it is failing for PG15.

This is a feature, not a bugfix. Such stuff isn't backpatched. At least, there
is some risk of breaking someone's regression tests. It is not good for a stable
branch.

-- 
regards, Andrei Lepikhov,
pgEdge

  6. Re: Show hashed SAOP decision in EXPLAIN

    Nishant Sharma <nishant.sharma@enterprisedb.com> — 2026-06-25T11:31:36Z

    Got it. Thank you!


Thanks,
Nishant Sharma,
EDB, Pune.
https://www.enterprisedb.com/


On Thu, Jun 25, 2026 at 4:11 PM Andrei Lepikhov <lepihov@gmail.com> wrote:

> On 25/06/2026 12:37, Nishant Sharma wrote:
> > v1 looks good based on my understanding.
> >
> > What about back-porting? If this is for PG20, I checked the v1 patch up
> to PG15.
> >
> > From MASTER to PG16 make check world passed, but it is failing for PG15.
>
> This is a feature, not a bugfix. Such stuff isn't backpatched. At least,
> there
> is some risk of breaking someone's regression tests. It is not good for a
> stable
> branch.
>
> --
> regards, Andrei Lepikhov,
> pgEdge
>