> Upthread [0], Andres suggested dispatching to a different implementation for > compile-time-known small lengths. Have you looked into that? In your > original post, you noted a 14% regression for records smaller than 256 bytes, > which is not an uncommon case for Postgres. IMO we should try to mitigate > that as much as possible.
Hi, Ok I added a patch that exposed a new macro CRC32C_COMP_SMALL for targeted fixed size < 256 use cases in Postgres. As for mitigating the regression in general, I have not been able to work up a fallback (i.e. <256 bytes) that doesn't involve runtime checks which cause latency. I also attempted to change the AVX512 fallback from the current algorithm in the avx512 implementation to the SSE original implementation, but I am not seeing any real difference for this use case in performance. I am open to any other suggestions. Paul
0001-v3-Refactor-Move-all-HW-checks-to-common-file.patch
Description: 0001-v3-Refactor-Move-all-HW-checks-to-common-file.patch
0002-v3-Feat-Add-support-for-the-SIMD-AVX-512-crc32c-algorit.patch
Description: 0002-v3-Feat-Add-support-for-the-SIMD-AVX-512-crc32c-algorit.patch
0003-v3-Feat-Targeted-use-of-legacy-crc32c.patch
Description: 0003-v3-Feat-Targeted-use-of-legacy-crc32c.patch
