Inefficiency in recent pgtz patch
От | Tom Lane |
---|---|
Тема | Inefficiency in recent pgtz patch |
Дата | |
Msg-id | 28648.1117312838@sss.pgh.pa.us обсуждение исходный текст |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: