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
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 |