| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at> |
| 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:30:57 |
| Message-ID: | 7198.1120743057@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at> writes:
> Only workable solution would imho be to write the LSN to each 512
> byte block (not that I am propagating that idea).
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?). What we *could* do is calculate a page-level CRC and
store it in the page header just before writing out. Torn pages
would then manifest as a wrong CRC on read. No correction ability,
but at least a reliable detection ability.
However, this will do nothing to solve the performance problem if
the core of that problem is the cost of computing page-sized CRCs :-(
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-07-07 13:38:08 | Re: Checkpoint cost, looks like it is WAL/CRC |
| Previous Message | Zeugswetter Andreas DAZ SD | 2005-07-07 10:11:43 | Re: Checkpoint cost, looks like it is WAL/CRC |