• Tom Lane's avatar
    Improve performance of timezone loading, especially pg_timezone_names view. · af2c5aa8
    Tom Lane authored
    tzparse() would attempt to load the "posixrules" timezone database file on
    each call.  That might seem like it would only be an issue when selecting a
    POSIX-style zone name rather than a zone defined in the timezone database,
    but it turns out that each zone definition file contains a POSIX-style zone
    string and tzload() will call tzparse() to parse that.  Thus, when scanning
    the whole timezone file tree as we do in the pg_timezone_names view,
    "posixrules" was read repetitively for each zone definition file.  Fix
    that by caching the file on first use within any given process.  (We cache
    other zone definitions for the life of the process, so there seems little
    reason not to cache this one as well.)  This probably won't help much in
    processes that never run pg_timezone_names, but even one additional SET
    of the timezone GUC would come out ahead.
    
    An even worse problem for pg_timezone_names is that pg_open_tzfile()
    has an inefficient way of identifying the canonical case of a zone name:
    it basically re-descends the directory tree to the zone file.  That's not
    awful for an individual "SET timezone" operation, but it's pretty horrid
    when we're inspecting every zone in the database.  And it's pointless too
    because we already know the canonical spelling, having just read it from
    the filesystem.  Fix by teaching pg_open_tzfile() to avoid the directory
    search if it's not asked for the canonical name, and backfilling the
    proper result in pg_tzenumerate_next().
    
    In combination these changes seem to make the pg_timezone_names view
    about 3x faster to read, for me.  Since a scan of pg_timezone_names
    has up to now been one of the slowest queries in the regression tests,
    this should help some little bit for buildfarm cycle times.
    
    Back-patch to all supported branches, not so much because it's likely
    that users will care much about the view's performance as because
    tracking changes in the upstream IANA timezone code is really painful
    if we don't keep all the branches in sync.
    
    Discussion: https://postgr.es/m/27962.1493671706@sss.pgh.pa.us
    af2c5aa8
localtime.c 42.9 KB