I have just noticed that this patch:* Implements a hash-table cache of loaded tables, so we don't haveto read and parse
theTZ file everytime we change a timezone. Whilenot necesasry now (we don't change timezones very often), I beleivethis
willbe necessary (or at least good) when "multiple timezonesin the same query" is eventually implemented. And
code-wise,thiswas the time to do it.
balloons the working store of every backend process by something over 5
megabytes:
Timezones: 5678768 total in 19 blocks; 3904 free (0 chunks); 5674864 used
The reason is that during postmaster start we load every single timezone
definition in the zic database whilst searching for the one that matches
the system timezone most closely. Because pg_tzset is designed to
unconditionally put every loaded timezone into the hashtable, that means
the postmaster ends up with copies of everything, and then all that junk
is inherited via fork by every backend.
I'm not sure about the actual cost of inheriting data that we (probably)
don't ever change, but this seems like a bad idea in principle,
considering that 99% of backends will likely have a use for only one
timezone value.
Please fix it. Possibly pg_tzset could take an extra argument
indicating whether or not to cache the data. Or maybe score_timezone
shouldn't use pg_tzset.
regards, tom lane
