Re: Optimize mul_var() for var1ndigits >= 8
От | Tom Lane |
---|---|
Тема | Re: Optimize mul_var() for var1ndigits >= 8 |
Дата | |
Msg-id | 2887629.1722292296@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Optimize mul_var() for var1ndigits >= 8 (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: Optimize mul_var() for var1ndigits >= 8
|
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: