Re: Performance Improvement by reducing WAL for Update Operation - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Performance Improvement by reducing WAL for Update Operation
Date
Msg-id 20140211163741.GD2289@momjian.us
Whole thread Raw
In response to Re: Performance Improvement by reducing WAL for Update Operation  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Performance Improvement by reducing WAL for Update Operation  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Performance Improvement by reducing WAL for Update Operation  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Feb  5, 2014 at 10:57:57AM -0800, Peter Geoghegan wrote:
> On Wed, Feb 5, 2014 at 12:50 AM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
> >> I think there's zero overlap. They're completely complimentary features.
> >> It's not like normal WAL records have an irrelevant volume.
> >
> >
> > Correct. Compressing a full-page image happens on the first update after a
> > checkpoint, and the diff between old and new tuple is not used in that case.
> 
> Uh, I really just meant that one thing that might overlap is
> considerations around the choice of compression algorithm. I think
> that there was some useful discussion of that on the other thread as
> well.

Yes, that was my point.  I though the compression of full-page images
was a huge win and that compression was pretty straight-forward, except
for the compression algorithm.  If the compression algorithm issue is
resolved, can we move move forward with the full-page compression patch?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Review: tests for client programs
Next
From: Bruce Momjian
Date:
Subject: Re: [PERFORM] encouraging index-only scans