| From: | Andres Taylor <andres(at)taylor(dot)se> |
|---|---|
| To: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Subject: | Re: Remove redundant DISTINCT when GROUP BY already guarantees uniqueness |
| Date: | 2026-06-22 08:44:22 |
| Message-ID: | CAFJHCweR5tbr9GsqofWbmZXZOJbsYj8OL=ihjR3MTg933B8Shw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I’ve signed up as reviewer for the CF entry, so I wanted to summarize
where I think this stands.
After reviewing v1 and the discussion, I think the optimization is
worthwhile, but the current patch needs a small correctness fix before
it can move forward.
The target-list SRF case discussed earlier in the thread is a
correctness issue: GROUP BY may produce one row, but SRF expansion
happens before DISTINCT, so removing DISTINCT can change the query
result.
At minimum, I think v1 needs a guard for that case and a regression
test. That seems like a fairly contained revision.
There is also a broader design question about whether this should
eventually be handled through planner-level uniqueness infrastructure,
as David raised earlier in the thread. I don’t think the current patch
needs to answer that entire question before v2, but it does seem
useful context for where this optimization might fit longer term.
So my review conclusion for the current CF entry is:
* v1 needs revision before it can proceed
* I’ll mark the entry Waiting on Author for now, unless others think a
different status is more appropriate
* there is a broader planner-uniqueness question here, but the
immediate issue is the target-list SRF correctness case
I already have Antonín’s UniqueKeys series rebased onto master and
passing its tests, as linked earlier in the thread. I’m happy to keep
pushing on that direction if that’s the most useful next step.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yingying Chen | 2026-06-22 08:46:45 | Re: Fix handling of copy_file_range() return value |
| Previous Message | shveta malik | 2026-06-22 08:38:21 | Re: Proposal: Conflict log history table for Logical Replication |