On Mon, Jul 29, 2024 at 4:41 PM Joel Jacobson <j...@compiler.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
