MIME-Version: 1.0
References: 
 <CANWCAZYzx7a7E9AY16Jt_U3+GVKDADfgApZ-42SYNiig8dTnFA@mail.gmail.com>
 <CANWCAZbsx5VY-F5RVvZ5H1abBWcinMY90gNra6EbdGS1CTx=7g@mail.gmail.com>
 <CANWCAZaN8kW6o7Ymc_jzPO_Z5SqekQTTNra3xTGYTH+cjrVp8g@mail.gmail.com>
 <269A8FB9-6D43-43CF-A6FE-52D28CBDB8A9@Outlook.com>
 <CANWCAZZiMGj6QuHfyBPv9at7xn23NPAz4nit=G6fr26V+h8MKg@mail.gmail.com>
 <F7935986-4E3D-477C-B45C-878420B45C0D@gmail.com>
 <CANWCAZaKRzsYPn9YWRR8g5dkX-ep_jgyUb4r3KFekK5ZTNo7ew@mail.gmail.com>
 <606C775A-4C1A-482B-BE7D-2E7A46AE14B9@gmail.com>
In-Reply-To: <606C775A-4C1A-482B-BE7D-2E7A46AE14B9@gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
Date: Thu, 4 Dec 2025 12:30:52 +0700
Message-ID: 
 <CANWCAZaBeDPfF0sCdSssRXv6nBZeRP8Z=OO1731zsoUC58U5_Q@mail.gmail.com>
Subject: Re: tuple radix sort
To: Chao Li <li.evan.chao@gmail.com>
Cc: Chengpeng Yan <chengpeng_yan@outlook.com>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
 Peter Geoghegan <pg@bowt.ie>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CANWCAZaBeDPfF0sCdSssRXv6nBZeRP8Z%3DOO1731zsoUC58U5_Q%40mail.gmail.com>
Precedence: bulk

On Wed, Dec 3, 2025 at 3:22=E2=80=AFPM Chao Li <li.evan.chao@gmail.com> wro=
te:
> I played with this again today and found an optimization that seems to dr=
amatically improve the performance:
>
> ```
> +static void
> +radix_sort_tuple(SortTuple *begin, size_t n_elems, int level, Tuplesorts=
tate *state)
> +{
> +       RadixPartitionInfo partitions[256] =3D {0};
> +       uint8_t         remaining_partitions[256] =3D {0};
> ```
>
> Here partitions and remaining_partitions are just temporary buffers, allo=
cating 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