Re: Checkpoint cost, looks like it is WAL/CRC

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: josh(at)agliodbs(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: Checkpoint cost, looks like it is WAL/CRC
Date: 2005-07-22 20:12:05
Message-ID: 16155.1122063125@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Bruce,
>> Did you test with full_page_writes on and off?

> I didn't use your full_page_writes version because Tom said it was
> problematic. This is CVS from July 3rd.

We already know the results: should be equivalent to the hack Josh
tried first.

So what we know at this point is that dumping full pages into WAL is
expensive, and that the CRC calculation cost is not the main expense.
(I suppose that this indicates the reduction to 32-bit CRC was
helpful, because previous measurements sure suggested that CRC costs
were important ...)

What we still don't know is exactly where the main expense *is*.
Is it I/O, WAL buffer lock contention, or what? I think the next
step is to vary the WAL-related parameters (wal_buffers,
wal_sync_method, and fsync) and see if we can learn anything that way.
It's entirely plausible that the optimal values for those have changed
due to our recent hacking.

(Note: turning off fsync is of course not a production option, but
it would be helpful to try it here --- it should give us a reading
on whether disk I/O wait is the culprit or not.)

I'd recommend that you *not* update to CVS tip, as that wouldn't
accomplish much except call into question any comparisons to the
runs you've already done. There are a number of unrelated changes
this month that could have side-effects on performance.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2005-07-22 20:15:45 Re: Checkpoint cost, looks like it is WAL/CRC
Previous Message Andrew Dunstan 2005-07-22 19:55:37 Re: Imprecision of DAYS_PER_MONTH