Skip site navigation (1) Skip section navigation (2)

Re: COMMIT NOWAIT Performance Option

From: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Subject: Re: COMMIT NOWAIT Performance Option
Date: 2007-02-28 03:43:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 2/27/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> I suggested a while back implementing torn page detection by writing a
> sequential number ever 512 bytes in the blocks. (I was talking about WAL at
> the time but the same principle applies.) Do it at the smgr layer using
> readv/writev and the upper layers need never know their data wasn't contiguous
> on disk. The only effect would be to shorten page sizes by 16 bytes which
> would be annoying but much less so than full_page_writes.

First, rather than using 16-bytes per page and having to deal with
handling the non-contiguous space, why not just use a page-level
checksum like everyone else?  Most of the systems I've seen seem to
employ a simple CRC16 or CRC32.

Second, unless I'm missing something, I don't see how your algorithm
is going to work as each 512 byte chunk of the block will *always*
have the same sequential byte value.  That is, unless you have some
way of preventing wraparound at 255 without adding additional block

Lastly, from a performance perspective, it's going to be faster to
compute the entire page's checksum than it would be to check the
sequence every 512 bytes and perform the space adjustment.

Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation            | fax: 732.331.1301
33 Wood Ave S, 3rd Floor            | jharris(at)enterprisedb(dot)com
Iselin, New Jersey 08830            |

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-02-28 03:48:25
Subject: Re: Resumable vacuum proposal and design overview
Previous:From: Bruce MomjianDate: 2007-02-28 03:03:58
Subject: Re: [HACKERS]

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group