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

From: "Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Bruno Wolff III" <bruno(at)wolff(dot)to>, "Greg Stark" <gsstark(at)mit(dot)edu>, "Russell Smith" <mr-russ(at)pws(dot)com(dot)au>, <josh(at)agliodbs(dot)com>, "Postgres Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Checkpoint cost, looks like it is WAL/CRC
Date: 2005-07-07 13:55:07
Message-ID: E1539E0ED7043848906A8FF995BDA57945BA95@m0143.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>> Only workable solution would imho be to write the LSN to each 512
byte
>> block (not that I am propagating that idea).

"Only workable" was a stupid formulation, I meant a solution that works
with
a LSN.

> We're not doing anything like that, as it would create an
> impossible space-management problem (or are you happy with
> limiting tuples to 500 bytes?).

To do it, a layer between physical storage and row workmemory
would need to be inserted, of course that would add a lot of overhead.
I guess more overhead than computing a page crc.

> We still don't know enough about the situation to know what a solution
might look like.
> Is the slowdown Josh is seeing due to the extra CPU cost of the CRCs,
or the extra I/O cost,
> or excessive locking of the WAL-related data structures while we do
this stuff, or ???.
> Need more data.

Yes, especially the 10 sec instead of 1 sec response times look very
suspicious.

Andreas

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2005-07-07 14:30:29 windows regression failure - prepared xacts
Previous Message Tom Lane 2005-07-07 13:51:11 Re: A couple of patches for PostgreSQL 64bit support