On Tue, Jul 30, 2024, at 00:31, Tom Lane wrote:
> Dean Rasheed <dean.a.rasheed@gmail.com> writes:
>> On Mon, 29 Jul 2024 at 21:39, Joel Jacobson <joel@compiler.org> wrote:
>>> I think it's non-obvious if the separate code paths for 32-bit and 64-bit,
>>> using `#if SIZEOF_DATUM < 8`, to get *fast* 32-bit support, outweighs
>>> the benefits of simpler code.
>
>> Looking at that other thread that you found [1], I think it's entirely
>> possible that there are people who care about 32-bit systems, which
>> means that we might well get complaints, if we make it slower for
>> them. Unfortunately, I don't have any way to test that (I doubt that
>> running a 32-bit executable on my x86-64 system is a realistic test).
>
> I think we've already done things that might impact 32-bit systems
> negatively (5e1f3b9eb for instance), and not heard a lot of pushback.
> I would argue that anyone still running PG on 32-bit must have pretty
> minimal performance requirements, so that they're unlikely to care if
> numeric_mul gets slightly faster or slower. Obviously a *big*
> performance drop might get pushback.
Thanks for guidance. Sounds reasonable to me.
Noted from 5e1f3b9eb:
"While it adds some space on 32-bit machines, we aren't optimizing for that case anymore."
In this case, the extra 32-bit numeric_mul code seems to be 89 lines of code, excluding comments.
To me, this seems like quite a lot, so I lean on thinking we should omit that code for now.
We can always add it later if we get pushback.
/Joel
