| From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: A performance issue with Memoize |
| Date: | 2024-01-27 04:00:01 |
| Message-ID: | 59a0c55e-2787-61ae-beb1-1665baeaf49f@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello,
27.01.2024 00:09, Tom Lane wrote:
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
>> On Sat, 27 Jan 2024 at 09:41, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> drongo and fairywren are consistently failing the test case added
>>> by this commit. I'm not quite sure why the behavior of Memoize
>>> would be platform-specific when we're dealing with integers,
>>> but ...
>> Maybe snprintf(buf, "%.*f", 0, 5.0 / 2.0); results in "3" on those
>> rather than "2"?
>> Looking at the code in fmtfloat(), we fallback on the built-in snprintf.
> Maybe ... I don't have a better theory.
FWIW, I've found where this behaviour is documented:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/sprintf-sprintf-l-swprintf-swprintf-l-swprintf-l?view=msvc-170
(I've remembered a case with test/sql/partition_prune from 2020, where
sprintf on Windows worked the other way.)
Best regards,
Alexander
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Borodin | 2024-01-27 04:58:18 | Re: MultiXact\SLRU buffers configuration |
| Previous Message | Amit Kapila | 2024-01-27 03:43:15 | Re: Synchronizing slots from primary to standby |