Re: Performance Improvement by reducing WAL for Update Operation

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com>
Subject: Re: Performance Improvement by reducing WAL for Update Operation
Date: 2014-02-05 08:50:03
Message-ID: 52F1FB3B.80506@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 02/04/2014 11:58 PM, Andres Freund wrote:
> On February 4, 2014 10:50:10 PM CET, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
>> On Tue, Feb 4, 2014 at 11:11 AM, Andres Freund <andres(at)2ndquadrant(dot)com>
>> wrote:
>>>> Does this feature relate to compression of WAL page images at all?
>>>
>>> No.
>>
>> So the obvious question is: where, if anywhere, do the two efforts
>> (this patch, and Fujii's patch) overlap? Does Fujii have any concerns
>> about this patch as it relates to his effort to compress FPIs?
>
> 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.

Compressing full page images makes a difference if you're doing random
updates across a large table, so that you only update each buffer 1-2
times. This patch will have no effect in that case. And when you update
the same page many times between checkpoints, the full-page image is
insignificant, and this patch has a big effect.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2014-02-05 10:42:33 Re: GIN improvements part2: fast scan
Previous Message Heikki Linnakangas 2014-02-05 08:44:20 Re: CacheInvalidateRelcache in btree is a crummy idea