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

Re: Logical to physical page mapping

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jan Wieck <JanWieck(at)yahoo(dot)com>,PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Logical to physical page mapping
Date: 2012-11-06 03:11:56
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Mon, Oct 29, 2012 at 07:05:39AM -0400, Robert Haas wrote:
> Yet another idea we've tossed around is to make only vacuum records
> include FPWs, and have the more common heap insert/update/delete
> operations include enough information that they can still be applied
> correctly even if the page has been "torn" by the previous replay of
> such a record.  This would involve modifying the recovery algorithm so
> that, until consistency is reached, we replay all records, regardless
> of LSN, which would cost some extra I/O, but maybe not too much to
> live with?  It would also require that, for example, a heap-insert
> record mention the line pointer index used for the insertion;
> currently, we count on the previous state of the page to tell us that.
>  For checkpoint cycles of reasonable length, the cost of storing the
> line pointer in every WAL record seems like it'll be less than the
> cost needing to write an FPI for the page once per checkpoint cycle,
> but this isn't certain to be the case for all workloads.

This last idea has the most promise for me.  Vacuum is far less common
than row modification writes.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

In response to

pgsql-hackers by date

Next:From: Karl O. PincDate: 2012-11-06 03:41:13
Subject: Re: Doc patch, distinguish sections with an empty row in error code table
Previous:From: Andrew DunstanDate: 2012-11-06 02:37:30
Subject: Re: Pg_upgrade speed for many tables

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