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
I've tested this now. Build seems to work, at least in the basic sense.
A regression:
In buildenv.bat i have set CONFIG=Debug, there appears tobe no way to
do that anymore?
Also, vcregress doesn't work for me. I put in buildenv.pl:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Has anyone looked what other changes there's been to the code in tz
library?
Yeah, we need to re-sync that code --- one big item we are missing is
support for 64-bit timezone data (hence, tz info beyond 2038). I don't
really want to touch it for 8.3
Magnus Hagander wrote:
I've tested this now. Build seems to work, at least in the basic sense.
A regression:
In buildenv.bat i have set CONFIG=Debug, there appears tobe no way to
do that anymore?
updated build.pl attached that should pick that up.
Also, vcregress doesn't work for me.
On Tue, 2007-09-18 at 18:27 -0700, Neil Conway wrote:
The builtin corr() aggregate doesn't produce the correct results in some
circumstances.
Applied to HEAD and REL8_2_STABLE.
-Neil
---(end of broadcast)---
TIP 5: don't forget to increase
Here are various fixes for syslogger.
- syslogger_parseArgs_assert.patch (bug #3621)
The assertion in syslogger_parseArgs() was wrong. The number of
arguments passed to syslogger is changed to 4 in 8.1 or later.
This patch should be appled to 8.1, 8.2 and 8.3dev.
-
