| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Fix GROUP BY ALL handling of ORDER BY operator semantics |
| Date: | 2026-07-13 20:10:22 |
| Message-ID: | A0B7C417-5710-47B3-8FA2-C0DDA518DA07@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 29 Jun 2026, at 09:20, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> The fix mostly refactors the existing logic so the GROUP BY ALL path also handles the ORDER BY sort clause. See the attached patch for details.
Thanks for the report and the patch, I am going to study it a bit more but I
have a few small comments on the patch.
+/*
+ * Add a targetlist entry to the GROUP BY list, copying matching ORDER BY
+ * operator information if available.
+ */
This comment is a bit light for such an important routine. The foreach has a
really great comment, I think we should move some (most?) of it to the function
comment.
- *flatresult = lappend(*flatresult, grpc);
+ grouplist = lappend(grouplist, grpc);
found = true;
break;
Now that we are in an external function, we could just return grouplist here
instead of breaking with a flag. The code outside the foreach can then call
addTargetToGroupList directly since we know that if we reach thus far there was
no match.
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-07-13 20:17:28 | Re: hashjoins vs. Bloom filters (yet again) |
| Previous Message | Matheus Alcantara | 2026-07-13 19:26:00 | Re: hashjoins vs. Bloom filters (yet again) |