Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array

From: Kirill Reshke <reshkekirill(at)gmail(dot)com>
To: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array
Date: 2025-10-18 08:59:40
Message-ID: CALdSSPigR5SqwqA_KFZOCDH8jw26Mj8V6tOdL5d_AgujjwPe5w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 18 Oct 2025 at 12:50, Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> Hi Hackers,

Hi!

> The SnapBuildPurgeOlderTxn function previously used a suboptimal
> method to remove old XIDs from the committed.xip array. It allocated a
> temporary workspace array, copied the surviving elements into it, and
> then copied them back, incurring unnecessary memory allocation and
> multiple data copies.
>
> This patch refactors the logic to use a standard two-pointer, in-place
> compaction algorithm. The new approach filters the array in a single
> pass with no extra memory allocation, improving both CPU and memory
> efficiency.
>
> No behavioral changes are expected. This resolves a TODO comment
> expecting a more efficient algorithm.
>

Indeed, these changes look correct.
I wonder why b89e151054a0 did this place this way, hope we do not miss
anything here.

Can we construct a microbenchmark here which will show some benefit?

--
Best regards,
Kirill Reshke

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-10-18 11:17:57 Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Previous Message Xuneng Zhou 2025-10-18 07:49:40 Optimize SnapBuildPurgeOlderTxn: use in-place compaction instead of temporary array