> On Thu, Oct 24, 2013 at 11:14:14PM +0300, Heikki Linnakangas wrote: > > On 24.10.2013 23:07, Josh Berkus wrote:
> > >What kind of overhead are we talking about here? > >
> > One extra WAL record whenever a hint bit is set on a page, for the > > first time after a checkpoint. In other words, a WAL record needs to > > be written in the same circumstances as with page checksums, but the > > WAL records are much smaller as they don't need to contain a full > > page image, just the block number of the changed block. > > > > Or maybe we'll write the full page image after all, like with page > > checksums, just without calculating the checksums. It might be > > tricky to skip the full-page image, because then a subsequent change > > of the page (which isn't just a hint-bit update) needs to somehow > > know it needs to take a full page image even though a WAL record for > > it was already written. > > Sorry to be replying late to this, but while I am not worried about the > additional WAL volume, does this change require the transaction to now > wait for a WAL sync to disk before continuing?
I don't think so. There's extra WAL written, but there's no flush-and-wait until end of transaction (as has always been).
But if the transaction would not have otherwise generated WAL (i.e. a select that did not have to do any HOT pruning, or an update with zero rows matching the where condition), doesn't it now have to flush and wait when it would otherwise not?
