From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> |
Subject: | Re: Performance improvements for src/port/snprintf.c |
Date: | 2018-10-03 16:22:13 |
Message-ID: | 27041.1538583733@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-10-03 12:07:32 -0400, Tom Lane wrote:
>> [ scratches head ... ] How would that work? Seems like it necessarily
>> adds a strlen() call to whatever we'd be doing otherwise. palloc isn't
>> going to be any faster just from asking it for slightly fewer bytes.
>> I think there might be something wrong with your test scenario ...
>> or there's more noise in the numbers than you thought.
> I guess the difference is that we're more likely to find reusable chunks
> in aset.c and/or need fewer OS allocations. As the memory is going to
> be touched again very shortly afterwards, the cache effects probably are
> neglegible.
> The strlen definitely shows up in profiles, it just seems to save at
> least as much as it costs.
> Doesn't strike me as THAT odd?
What it strikes me as is excessively dependent on one particular test
scenario. I don't mind optimizations that are tradeoffs between
well-understood costs, but this smells like handwaving that's going to
lose as much or more often than winning, once it hits the real world.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Arthur Zakirov | 2018-10-03 16:24:28 | Re: libpq host/hostaddr/conninfo inconsistencies |
Previous Message | Bossart, Nathan | 2018-10-03 16:20:42 | Re: Add SKIP LOCKED to VACUUM and ANALYZE |