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
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 |