Re: Is *fast* 32-bit support still important?

On Mon, Jul 29, 2024 at 4:41 PM Joel Jacobson <joel(at)compiler(dot)org> wrote:
> To me, it's non-obvious whether introducing `#if SIZEOF_DATUM < 8` with
> separate 32-bit and 64-bit code paths is worthwhile to maintain performance
> for both.

I feel like it's probably mostly up to the patch author. Reviewers
and/or the eventual committer might propose to reverse whatever
decision the patch author made, but personally, I wouldn't bounce a
patch for either having or not having separate code paths, unless
there was some particular reason to believe that whatever decision the
patch author made was likely to cause a problem.

One generally difficult thing about working in the PostgreSQL
community is that we have pretty limited formal decision-making
structures. A consensus on the list is valid only until the issue is
relitigated, which can happen at any time and for any reason. With
infrequent exceptions such as RMT or core pronouncements, a previous
consensus doesn't bind people who weren't participants in the previous
discussion, or even people who were. Everybody is free to change their
mind at any time. For that reason, I often find it more helpful to
approach questions like this from a pragmatic standpoint: rather than
asking "what is the policy about X?" I find it better to ask "If I do
X, what is probably going to happen?"

What I think is: if you write a patch that caters mostly to 64-bit
systems, probably nobody will notice or care that the 32-bit
performance is not great, because there just aren't that many 32-bit
users left out there. I think it's been a very long time since we got
a complaint about 32-bit performance, or a patch to improve 32-bit
performance, but we get other kinds of performance-optimizing patches
all the time, for all sorts of things. Perhaps that's because we
haven't yet done anything too terrible to 32-bit performance, but it's
probably also that if you're running a 32-bit system in 2024, you're
probably not expecting it to come under serious load. You likely care
more about getting the job done with limited machine resources than
anything else. And you likely expect it to be slow. I don't actually
know how much we'd have to regress 32-bit performance before users
started to show up and complain about it, and I'm certainly not
recommending that we do so gratuitously. At the same time, evidence
that people are displeased with our current 32-bit performance or that
they care about improving our 32-bit performance is very thin on the
ground, AFAIK. If at some point people do start showing up to
complain, then we'll know we've gone too far and we can back off --
with the benefit of knowing what people are actually unhappy about at
that point, vs. what we think they might be unhappy about.

And on the other hand, if you take the opposite approach and write a
patch that includes a separate code path for 32-bit systems, as long
as it works and doesn't look terribly ugly, I bet nobody's going to
waste time demanding that you rip it out.

So I would just do whatever you feel like doing and then defend your
choice in the comments and/or commit message.

--
Robert Haas
EDB: http://www.enterprisedb.com