From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Joel Jacobson <joel(at)compiler(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimize mul_var() for var1ndigits >= 8 |
Date: | 2024-07-29 22:31:36 |
Message-ID: | 2887629.1722292296@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Mon, 29 Jul 2024 at 21:39, Joel Jacobson <joel(at)compiler(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kirill Reshke | 2024-07-29 22:32:19 | Re: Incremental View Maintenance, take 2 |
Previous Message | Jacob Champion | 2024-07-29 22:30:21 | Re: [PoC] Federated Authn/z with OAUTHBEARER |