From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Xiang Gao <Xiang(dot)Gao(at)arm(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CRC32C Parallel Computation Optimization on ARM |
Date: | 2023-10-24 21:37:45 |
Message-ID: | 4ceb7c74-b188-471d-b3bf-a11ec411fe46@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 25/10/2023 00:18, Nathan Bossart wrote:
> On Tue, Oct 24, 2023 at 04:09:54PM -0500, Nathan Bossart wrote:
>> I'm able to reproduce the speedup with the provided benchmark on an Apple
>> M1 Pro (which appears to have the required instructions). There was almost
>> no change for the 512-byte case, but there was a ~60% speedup for the
>> 4096-byte case.
>>
>> However, I couldn't produce any noticeable speedup with Heikki's pg_waldump
>> benchmark [0]. I haven't had a chance to dig further, unfortunately.
>> Assuming I'm not doing something wrong, I don't think such a result should
>> necessarily disqualify this optimization, though.
>
> Actually, since the pg_waldump benchmark likely only involves very small
> WAL records, it would make sense that there isn't much difference.
> *facepalm*
No need to guess, pg_waldump -z will tell you what the record size is.
And you can vary it by changing the checkpoint interval and/or pgbench
scale factor: if you checkpoint frequently or if the database is larger,
you get more full-page images which makes the records larger on average,
and vice versa.
--
Heikki Linnakangas
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-10-24 22:17:55 | Re: CRC32C Parallel Computation Optimization on ARM |
Previous Message | Nathan Bossart | 2023-10-24 21:20:56 | Re: Add new for_each macros for iterating over a List that do not require ListCell pointer |