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
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 |