| From: | John Naylor <johncnaylorls(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Chengpeng Yan <chengpeng_yan(at)outlook(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Subject: | Re: tuple radix sort |
| Date: | 2025-12-04 05:30:52 |
| Message-ID: | CANWCAZaBeDPfF0sCdSssRXv6nBZeRP8Z=OO1731zsoUC58U5_Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 3, 2025 at 3:22 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> I played with this again today and found an optimization that seems to dramatically improve the performance:
>
> ```
> +static void
> +radix_sort_tuple(SortTuple *begin, size_t n_elems, int level, Tuplesortstate *state)
> +{
> + RadixPartitionInfo partitions[256] = {0};
> + uint8_t remaining_partitions[256] = {0};
> ```
>
> Here partitions and remaining_partitions are just temporary buffers, allocating memory from stack and initialize them seems slow. By passing them as function parameters are much faster. See attached diff for my change.
The lesson here is: you can make it as fast as you like if you
accidentally blow away the state that we needed for this to work
correctly.
--
John Naylor
Amazon Web Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-12-04 05:32:47 | Re: Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE |
| Previous Message | Ajin Cherian | 2025-12-04 05:21:39 | Re: Improve pg_sync_replication_slots() to wait for primary to advance |