Re: Show hashed SAOP decision in EXPLAIN

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: Andrei Lepikhov <lepihov(at)gmail(dot)com>
Cc: Nishant Sharma <nishant(dot)sharma(at)enterprisedb(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Show hashed SAOP decision in EXPLAIN
Date: 2026-07-16 13:41:01
Message-ID: CAJTYsWXWKjo-TX0+Mm=rEfUCno_uZ1Mmx5_9243R3RqNtZ1gCw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, 22 Jun 2026 at 14:44, Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:

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

Thanks for the patch!

Post test suite, I spot-checked a hashed SAOP as an index condition
and x = ANY (ARRAY(SELECT ...)); both behave correctly.

One nit in the comment of a test case:
"Check that 'hashed' is actually bubbles up...", we may drop the "is".

Otherwise LGTM. Will mark it ready for committer.

Regards,
Ayush

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2026-07-16 13:45:05 Re: walsummarizer can get stuck when switching timelines
Previous Message Rafia Sabih 2026-07-16 13:37:17 Re: Allow table AMs to define their own reloptions