Re: pg_next_dst_boundary optimization

Heikki Linnakangas wrote:
> While profiling loading a table with timestamp columns with COPY, I
> spotted that a lot of time is spent in pg_next_dst_boundary. It scans a
> sorted array of time segments to find the one that the given timestamp
> falls within. That's slow when the array is big; GB timezone for example
> has > 200 segments.
>
> Attached is a patch to use binary search instead of linear search.

Digging deeper into this, that function is essentially the same as the
first part of localsub [1], which should also be changed to use binary
search. In fact, that's exactly what localsub does in the most recent
version of the tz library.

Has anyone looked what other changes there's been to the code in tz
library? Which version of tz is our code based on?

[1] Tom's post introducing pg_next_dst_boundary:
http://archives.postgresql.org/pgsql-hackers/2004-10/msg01066.php),

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com