Horton

Re: A performance issue with Memoize

Alexander Law <exclusion@gmail.com>

View thread View on postgr.es
From: Alexander Lakhin <exclusion@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, David Rowley <dgrowleyml@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-01-27T04:00:01Z
Lists: pgsql-hackers 
Hello,

27.01.2024 00:09, Tom Lane wrote:
> David Rowley <dgrowleyml@gmail.com> writes:
>> On Sat, 27 Jan 2024 at 09:41, Tom Lane <tgl@sss.pgh.pa.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

Commits

  1. Attempt to fix newly added Memoize regression test

  2. Compare varnullingrels too in assign_param_for_var().

  3. De-dupicate Memoize cache keys

  4. Improve NestLoopParam generation for lateral subqueries

  5. Avoid sharing PARAM_EXEC slots between different levels of NestLoop.