From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Daniel Farina <daniel(at)heroku(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Ants Aasma <ants(at)cybertec(dot)at>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Enabling Checksums |
Date: | 2013-03-23 04:26:27 |
Message-ID: | 514D2EF3.9050904@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/18/13 2:25 PM, Simon Riggs wrote:
> On 18 March 2013 19:02, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>> On Sun, 2013-03-17 at 22:26 -0700, Daniel Farina wrote:
>>> as long as I am able to turn them off easily
>>
>> To be clear: you don't get the performance back by doing
>> "ignore_checksum_failure = on". You only get around the error itself,
>> which allows you to dump/reload the good data.
>
> Given that the worst pain point comes from setting hint bits during a
> large SELECT, it makes sense to offer an option to simply skip hint
> bit setting when we are reading data (SELECT, not
> INSERT/UPDATE/DELETE). That seems like a useful option even without
> checksums. I know I have seen cases across many releases where setting
> that would have been good, since it puts the cleanup back onto
> VACUUM/writers, rather than occasional SELECTs.
+1
From | Date | Subject | |
---|---|---|---|
Next Message | Atri Sharma | 2013-03-23 04:29:29 | Re: Page replacement algorithm in buffer cache |
Previous Message | Jim Nasby | 2013-03-23 04:19:51 | Re: Enabling Checksums |