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