Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Дата
Msg-id CA+TgmoYGgrLazC_eHfBsH2N2YDMhUi6nK_hsXgM5LFmgoSSYVg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Список pgsql-hackers
On Tue, May 8, 2018 at 4:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Really the only thing here that jumps out as being unduly expensive for
> what it's doing is select_default_timezone.  That is, and always has been,
> a brute-force algorithm; I wonder if there's a way to do better?  We can
> probably guess that every non-Windows platform is using the IANA timezone
> data these days.  If there were some way to extract the name of the active
> timezone setting directly, we wouldn't have to try to reverse-engineer it.
> But I don't know of any portable way :-(

Who says we need a portable way?  If we had something that worked on
Linux and macOS, it would cover most developer environments.  I wonder
if readlink("/etc/localtime", buf, sz) might be a viable approach.
You could, at least, try any time zone you can derive that way first,
before you try any others.

Also, how about having a --timezone option for initdb?  Then you could
determine the time zone just once and pass it down to subsequent
initdb invocations.  Or just hardcode the regression tests to use some
fixed time zone, like Antarctica/Troll.  :-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Indexes on partitioned tables and foreign partitions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Indexes on partitioned tables and foreign partitions