On Wed, Nov 16, 2016 at 08:45:20PM +0000, Christian Ullrich wrote:
> * Noah Misch wrote:
> > I prefer the simplicity of abandoning the cache (patch 4), if it
> > performs decently.  Would you compare the performance of patch 1,
> > patches 1+2+3, and patches 1+2+4?  This should measure the right 
> > thing (after substituting @libdir@ for your environment):
> 
> Tested with release builds; Core i7-6700K (quad/HT; 4000 MHz).
> I did three runs each, and they were always within 0.5 % of each
> other's run time.
> 
> - patch 1 (now 1-3):         24 μs/iteration (24 s for 1e6)
> - patch 1+2+3 (now 1-5 + 8): 29 μs/iteration
> - patch 1+2+4 (now 1-7):     30 μs/iteration

Thanks for measuring; 6μs*9=54μs is a negligible addition to Windows backend
startup time.

On Wed, Nov 30, 2016 at 04:24:34PM +0000, Christian Ullrich wrote:
> * From: Michael Paquier
> > would be nice to mention in a code comment that this what Noah has
> > mentioned upthread: if a CRT loads while pgwin32_putenv() is
> > executing, the newly-loaded CRT will always have the latest value.
> 
> I fixed the existing comment by removing the last sentence that is in the 
> wrong place now, but I don't see the point in suddenly starting to explain 
> why it is done this way and not the other.
> 
> > Based on that 0006 will need a rebase, nothing huge though.
> 
> Done, new revisions attached.

I committed patches 1-7 with some comment changes, a pgindent, and other
cosmetic trivia.  (The file was pgindent-clean before this work.  Patch 6
still achieved the more-compact formatting you sought.)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to