MIME-Version: 1.0
Date: Thu, 15 Jan 2026 15:03:59 +0700
From: Oleg Tselebrovskiy <o.tselebrovskiy@postgrespro.ru>
To: John Naylor <johncnaylorls@gmail.com>
Cc: Andrew Kim <tenistarkim@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: Proposal for enabling auto-vectorization for checksum
 calculations
In-Reply-To: <CANWCAZbjdFnBiUmrBQC5vFFy0Fnn4SJG4AkkzGpTFhovodJdYQ@mail.gmail.com>
References: <20250911054220.3784-1-root@ip-172-31-36-228.ec2.internal>
 <CANWCAZYZQw-nzTXbx3Bk332VtY9_D7ksDsuMZ0A-iDZ53yG7Ng@mail.gmail.com>
 <CAK64mnfeWLBRbMfnOsag0vGTDnT84KJzpuei40nG0OHyw4SESw@mail.gmail.com>
 <CANWCAZa1b2rcvoK657SmcKwh2P2cgASQ1D-0JPj5d3LbfaAVgA@mail.gmail.com>
 <CAK64mneN20+sW5WhV+r7hMVo4Rd0z11B6=3L039rWMt1wK3nPg@mail.gmail.com>
 <CANWCAZZuS3sNgLRo8Z4AM=uY4zTmz=dH5D4Z9xV6K0CEuJ8Hdw@mail.gmail.com>
 <CAK64mnejn9AZMYz03e7HX8Uui35PihUuOy=b+iBG=YtRKx0Log@mail.gmail.com>
 <CANWCAZZ_0AQMk1HgHXHX+JaeBfy_4kzwHgTdqMptDA7zM+nm+Q@mail.gmail.com>
 <CAK64mnc6jbehHv5AHc84tVFRJg4zeMiFuvPX9xZkRpq0210MFA@mail.gmail.com>
 <CANWCAZY940P3wGOQAZWMLQL4MQGGyOu7WBjBEcn_gqcrr+NvAw@mail.gmail.com>
 <CAK64mne_oWN9d4mf+0c_5-4Emb9kRXA-OC05OJ4F_1fVqpjzDA@mail.gmail.com>
 <CANWCAZZcKYp+01u1QmkShfXVkUCCdxtJAgHT-61Vw0ALoWj47A@mail.gmail.com>
 <CAK64mne=Q_4VSpJ8f4RQB-yAThd4+i-BRYMvfdGOhvwJQdYoKQ@mail.gmail.com>
 <CANWCAZYg2MVbYTaczNYNC2kaPodtfB8toUfE2Mhp9kut=2wzEA@mail.gmail.com>
 <CAK64mnd9NE+xE18shrf-SSx-iwMVof=2DJ2y9_fOkQ5E2Abc5g@mail.gmail.com>
 <CANWCAZbjdFnBiUmrBQC5vFFy0Fnn4SJG4AkkzGpTFhovodJdYQ@mail.gmail.com>
Message-ID: <0be1b7b05726652ea0d83e8f72fd4cfe@postgrespro.ru>
Organization: Postgres Pro
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/0be1b7b05726652ea0d83e8f72fd4cfe%40postgrespro.ru>
Precedence: bulk

Can't respond to the original message about v10 of the patch for some
reason, so I'll respond here.

> So in v10 I separated the body of checksum_block to
> a semi-private header to provide hardware-specific definitions
> for core code, while also maintaining the same one that
> external code expects

I like the usage of a semi-internal header, less code duplication
is always good

> In the attached v10-0003, I went back to something more similar to v6,
> but incorporated Andrew's idea of using PG_CHECKSUM_INTERNAL to allow
> for flexibility. Now pg_filedump compiles without any changes, so
> that's a plus.

If I understand correctly, with how code is currently,
external programms can define PG_CHECKSUM_INTERNAL manually,
but then they won't have access to static functions inside of
checksum.c, so all you get is a pointer that leads nowhere, correct?
I'd like to think that speeding up checksum calculation is something
that some external programms could appreciate.

Is it possible to move pg_checksum_block_fallback,
pg_checksum_block_avx2, and pg_checksum_choose to checksum_impl.h?
It would mean moving all the hardware check to the same header as well.
Doesn't look or sound pretty, but this would allow external programms
to chose implementation the same way the core does it, but also just
change nothing and still have fallback code.

> For this to be commitable, I think (and I think Oleg agrees) that the
> feature detection should go in src/port. Some of us have been thinking
> of refactoring and centralizing the feature detection, and now may be
> a good time to do it.

I do agree with that. I thought that we can continue with v10 as-is,
commit it with hardware checks still in checksum.c and refactor it with
everything else, but with my proposition above (and even without it)
it seems that refactoring of hardware checks should come first.

Also, not moving all those checksum files to src/port saves us from
thinking about problems with meson and current external programs,
but, I think, that after hardware checks are refactored, we could
revisit the question of moving checksum[_impl].h/.c to src/port.

All in all, very happy to see progress on this!

Regards,
Oleg