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
- v1-0001-Show-hashed-ScalarArrayOpExpr-decision-in-EXPLAIN.patch (text/plain) patch v1-0001
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 →
-
Fix missed checks for hashability of container-type equality.
- 06e94eccfd91 19 (unreleased) cited