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

From Andres Freund
Subject Re: Performance Improvement by reducing WAL for Update Operation
Date
Msg-id 20140304115405.GA29018@awork2.anarazel.de
Whole thread Raw
In response to Re: Performance Improvement by reducing WAL for Update Operation  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On 2014-03-04 12:43:48 +0200, Heikki Linnakangas wrote:
> >>This ought to be tested with the new logical decoding stuff as it modified
> >>the WAL update record format which the logical decoding stuff also relies,
> >>but I don't know anything about that.
> >
> >Hm, I think all it needs to do disable delta encoding if
> >need_tuple_data (which is dependent on wal_level=logical).
> 
> That's a pity, but we can live with it.

Agreed. This is hardly the first optimization that only works for some
wal_levels.

> If we did this at a higher level and
> checked which columns have been modified, we could include just the modified
> fields in the record, which should to be enough for logical decoding. It
> might be even more useful for logical decoding too to know exactly which
> fields were changed.

Yea, I argued that way elsewhere in this thread. I do think we're going
to need per column info for further features in the near future. It's a
bit absurd that we're computing various sets of changed columns (HOT,
key, identity) plus the pre/postfix with this patchset.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Patch: show relation and tuple infos of a lock to acquire
Next
From: Simon Riggs
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe