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 br
Tom Lane wrote:
Josh Berkus 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
Josh Berkus 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
anything older t
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 broadcast)-
Josh Berkus 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 utilization doesn't
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:
http://khack.osdl.org/stp/302458/result
