| From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, cca5507 <cca5507(at)qq(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fix incorrect comments in tuplesort.c |
| Date: | 2025-12-08 01:20:00 |
| Message-ID: | 54DB79FF-2FE4-4CBC-B639-E50C027EFADF@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Dec 8, 2025, at 08:28, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> + * in grow_memtuples(). However, we don't consider array sizes
> + * less than 1024.
>
> Using "However" here indicates some exception to what's just been
> said, but there is no longer an exception. To write about what the
> 1024 is for, we might need to reverse engineer what that's for. I
> assume it's something like "Clamp at 1024 elements to avoid excessive
> reallocs of the array". Or perhaps that without the " of the array"
> part.
+1 for the “however” concern.
Also, I found 8ea3e7a75c might explain why we want initial memtuples array size to exceed ALLOCSET_SEPARATE_THRESHOLD. That's because we want to avoid switching between block chunk and separate chunk when growing.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-12-08 01:25:45 | Re: Extended Statistics set/restore/clear functions. |
| Previous Message | David Rowley | 2025-12-08 00:28:59 | Re: Fix incorrect comments in tuplesort.c |