Re: Show hashed SAOP decision in EXPLAIN

Andrei Lepikhov <lepihov@gmail.com>

From: Andrei Lepikhov <lepihov@gmail.com>
To: Nishant Sharma <nishant.sharma@enterprisedb.com>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2026-06-22T09:14:24Z
Lists: pgsql-hackers

Attachments

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

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.