Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfTfy-0029f4-2E for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 01:58:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vfTfw-002A39-2N for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jan 2026 01:58:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vfTfw-002A31-1D for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 01:58:28 +0000 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vfTfp-0008Jz-0K for pgsql-hackers@lists.postgresql.org; Tue, 13 Jan 2026 01:58:23 +0000 Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-b86eaf80979so40449366b.2 for ; Mon, 12 Jan 2026 17:58:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768269498; cv=none; d=google.com; s=arc-20240605; b=g+n8omMfUtMH2PgeWsuf1LjOOlILJljIW/fs6e6XSHWYUGHUHrQ1owDP16WNcypmyw hBJUSXP8euqr0NQpif9waa7CR2wjYVnBeK/3fjgehelwA6Y7JO2xcRKpnSmIy8EHpVwZ gOLik1PrWJjRAC2UoyAypjVIXWj+TCLZTkhAl8axZCekkmVmpA5jVbRZr3du78+ufPii s63R6t1zH0xErfsCRHSFMOHdkJFxl7iwIPVMLerfa/pC0tbMps7W+iuI4LLGY3ZzijHR sq18JYFPxoGket/fVQ/X+tnjVfnDg5j2CxXSTzv0MhDQ+bJcA9pgFxxh9nDl48pQ2a2/ n5+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=PwEp6WCqOIMaWjUCrWdZ9cYjWtBeA6t1DqmIU0Q/ykM=; fh=UoByW8EJreMnUMGNidg5CzEzkUZWxrWTn9mzUE1n6vI=; b=Y5yrSU0ABuvw5gnYSt0q0vjxuUkKmZ3/p6co5KidrK3cqEjOT5w+OM7WdZmWMDXbCK OmEBt3acxwIoy8nRA97niG7Ce2gG0JxXdWBZc9Zu90kNSmkOJVjaVYxpCKNHVJTp++qF zrSkyOH71P9dXaOfD4xnTT4drgE5xfDdrCeT7ucP31dc0Oysq4R3Xd3U9lMwyQJMhCF6 zvJ4QCA8/A06LFrwJA7Iu/0vWVuGUIDVEQgp+UBbrAtzsvBE2z4J+eZKwv3aRKXGqbu7 rNhtV19mdBwf5wQJ5hPkZtmDKIE5jbwVVHcPZOBic32whJNPXsOCqguVeaIHFgo83ObM 3ZnA==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768269498; x=1768874298; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PwEp6WCqOIMaWjUCrWdZ9cYjWtBeA6t1DqmIU0Q/ykM=; b=MEcEuJ0p95VgzUu57cl7/Nlklt/S4cLh/aK1nhoJNVaN7Vk9e4wXsPuP79TdFQQ7OI 16ANtAGcRw60BGqxLMqjpEP/+PebVhsgJgf8w9xGpT8ImYwN6v7JQff2MV3eDzhYWBBt DeWmyOLU1HUcbBELHUk3k4jtW7UeZeIVZKQ8JTvC4RaoeYQGzSUOecibu/ZQctqQzupT eycdWqCywPsjSSZjqKc4wjlY07PYQ/C+OQA3x/KYcpJXtPayj1cu0jJIPZ/NeeBuXAT1 gxQeeZVk0LVP1ydLtCyW3SdMptZt9MyQ60DCOP/84H9b/afSEuRGsR5uGqyDGHrkSbBc elmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768269498; x=1768874298; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=PwEp6WCqOIMaWjUCrWdZ9cYjWtBeA6t1DqmIU0Q/ykM=; b=NkS+3k+mUWY5RMTIIZwJ0yGlIWsJteSdNWIOcdmgdzkIrN4NpI6q7y+KFXNAC5CNAE N7gIgWZ735vYlpmn1W34B6Fe85zy7+FrNs/QnScjdh0n7ImW2Bksek2lth1lVA82NLpj aB16cGBvZLQfAUlydh6fn4GrlaEzODneIiDZPPnX7wlQrV2STC3xKNlvD/ttM00YbrTk /of05m3DWCTDBBzEbpNdgEroIbMZQHAP899q0Qbz/FQElRUzk8hwwMKxK8HH7ToPBhNj fsxJeY3WvvpcidAJbbhYUX6e2tGfkxu4yu0Md8o9rOWwkhAW7TizWzerAMYPrXA5m4sk p40A== X-Gm-Message-State: AOJu0YyK8dCYxZTJOhXbXCo5uvHRslfRWtPQNLlUCaFmI6BfwaJchV5C 73dgwNOk0XzH7WE/02kQ6WRM3PO84Mvw651WYoumxJc3B+PBfjD0Cr8P5gzsim/cXvRNn9Hpt9q wKRA/e9JDsdewJDBQ6m0R+m7tpXZfkDVUtTlG X-Gm-Gg: AY/fxX76Dn8+pMx3IE+nCUsDjTWGL0CPSFNTsPZxTaIeqdSRnhgf+cNGaE67zLUMHwF lGTUHaI78it/doUYBLWZS9xUdeca4rMc0ThtZxUcDvPrMwHqoT0MP0pAOd1/IU4khZKgV10hku2 f+vvFf5XZyFGJpvF9yBLhR54o8a4ShrsDA+kvgxvm7RoDDPjCmINFZMl7hA6jzl6iFd32zfjcm+ FgJ4lZqYMol0kUur8qh0YRfQQqodSgmVdb7yx0QH/kvcSU1QACxM2IPtW5DxzUDy/PiL3P62EZ5 RCmUkjpeqEz5ds9PSw== X-Google-Smtp-Source: AGHT+IHep7jPBA+Jg8rFVxp6gTfaLb9neE+DUaX2E1/LdroJxxpwTTQyu6o+J4yEVTPFTNgskyDG0ZDnB99gp2nyviQ= X-Received: by 2002:a05:6402:254f:b0:647:9bdd:3211 with SMTP id 4fb4d7f45d1cf-65097e3c766mr10652402a12.4.1768269497991; Mon, 12 Jan 2026 17:58:17 -0800 (PST) MIME-Version: 1.0 References: <20250911054220.3784-1-root@ip-172-31-36-228.ec2.internal> In-Reply-To: From: Andrew Kim Date: Mon, 12 Jan 2026 17:58:07 -0800 X-Gm-Features: AZwV_QhSrPLsDsth2CVocjG8maGBy3fTWg5m78QYPJCpHrD82E-iwi8YlqxiZOQ Message-ID: Subject: Re: Proposal for enabling auto-vectorization for checksum calculations To: John Naylor Cc: pgsql-hackers@lists.postgresql.org, Oleg Tselebrovskiy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi John, Thanks for taking the time to dig into this, I really appreciate the detailed analysis, especially catching the Meson CI failure, which I had unfortunately missed after v6. On Sun, Jan 11, 2026 at 3:19=E2=80=AFPM John Naylor wrote: > > On Thu, Nov 6, 2025 at 6:50=E2=80=AFAM Andrew Kim = wrote: > > The v9 patch series is attached. > > Sorry for the delay. I found some issues last month and needed to > consider the tradeoffs. > > First, apparently it has gone unnoticed by everyone, myself included, > that no version has passed Meson CI since v6: > > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5726 > > That's because `ninja -C build -t missingdeps` gives: > > Missing dep: src/port/libpgport_shlib_checksum.a.p/checksum.c.o uses > src/include/utils/errcodes.h (generated by CUSTOM_COMMAND) > Missing dep: src/port/libpgport_checksum.a.p/checksum.c.o uses > src/include/utils/errcodes.h (generated by CUSTOM_COMMAND) > Processed 2561 nodes. > Error: There are 2 missing dependency paths. > 2 targets had depfile dependencies on 1 distinct generated inputs > (from 1 rules) without a non-depfile dep path to the generator. > There might be build flakiness if any of the targets listed above are > built alone, or not late enough, in a clean output directory. > > In the back of my mind I was worried of consequences of something in > src/port depending on backend types, but hadn't seen any in my local > builds. It seems the proximate cause is the removal of this stanza > with no equivalent replacement: > > --- a/src/backend/storage/page/meson.build > +++ b/src/backend/storage/page/meson.build > @@ -1,14 +1,5 @@ > # Copyright (c) 2022-2025, PostgreSQL Global Development Group > > -checksum_backend_lib =3D static_library('checksum_backend_lib', > - 'checksum.c', > - dependencies: backend_build_deps, > - kwargs: internal_lib_args, > - c_args: vectorize_cflags + unroll_loops_cflags, > -) > - > -backend_link_with +=3D checksum_backend_lib > > The low-level algorithm doesn't care about database pages, only > integers, so first I tried to surgically isolate the concepts, but > that was too messy. > > 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. > > > - Provides public interfaces wrapping the basic implementation > > > - No code duplication (checksum.c includes checksum_impl.h) > > Upthread I mentioned "thin wrappers", but so far I haven't seen it in > any patch versions, so I don't think this term means the same thing to > you as it does to me (I saw pretty clear duplication in v9). It then > occurred to me that with function attribute targets, doing the naive > thing throws a compiler error IIRC -- namely just have a notional > function call that then gets inlined and re-targeted. 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 agree that the missing dependency reported by Meson is a real issue, not just a theoretical one. The removal of the backend-side checksum_backend_lib stanza without an equivalent dependency path explains the CI breakage clearly, and your diagnosis makes sense, v10-0003 approach, splitting the body of checksum_block into a semi-private implementation header while preserving the externally visible interface, that makes sense to me > > 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. Before going that far, I wanted to see what > people think of v10. I also agree with you (and Oleg) that feature detection really belongs in src/port, even if that means doing a bit more refactoring up front. As you said, this may actually be a good forcing function to finally consolidate feature detection in a cleaner way. I=E2=80=99m supportive of using v10 as the basis for further discussion and= iteration, cleaning up Meson dependency declarations so generated headers are properly ordered, refining the PG_CHECKSUM_INTERNAL usage if needed, and assisting with any additional refactoring required to keep src/port fully backend-agnostic. Thanks again for the careful review and for pushing this in a direction that=E2=80=99s more robust and committable. > > -- > John Naylor > Amazon Web Services