Tom,
The latest omit-the-hole change went in 2005-06-06 16:22 (EDT), so
anything older than that is probably not representative.
Looks like this was 5/29. Re-running the tests with current CVS now.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
Tom,
(I assume this *is* CVS tip, or near to it? The recent CRC32 and
omit-the-hole changes should affect the costs of this quite a bit.)
It was a recent build. When was CRC32 checked in?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
Josh Berkus josh@agliodbs.com writes:
(I assume this *is* CVS tip, or near to it? The recent CRC32 and
omit-the-hole changes should affect the costs of this quite a bit.)
It was a recent build. When was CRC32 checked in?
The latest omit-the-hole change went in 2005-06-06 16:22 (EDT), so
Tom Lane wrote:
Hm, notice that the processor utilization doesn't actually drop all that
much, so it seems it's not fundamentally an I/O storm kind of issue.
If I read the chart on the bottom of Josh's links correctly,
it looks to me like
the fast one is spending 50% CPU in user and 30% CPU
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
(I assume this *is* CVS tip, or near to it? The recent CRC32 and
omit-the-hole changes should affect the costs of this quite a bit.)
It was a recent build. When was CRC32 checked in?
The latest omit-the-hole change went in
Tom, folks,
I'm continuing to see a problem with checkpointing and clock-sweep.
Previously I thought that it was just the long checkpoint intervals on the
standard DBT2 test, but things get worse when you checkpoint more frequently:
60 minute checkpoint:
Josh Berkus josh@agliodbs.com writes:
So this is obviously a major performance problem. It could be fixed by
turning off checkpointing completely, but I don't think that's really
feasable. Any clue on why clock-sweep should be so slammed by checkpoints?
Hm, notice that the processor
