Re: Performance Improvement by reducing WAL for Update Operation

Andres Freund <andres@2ndquadrant.com>

From: Andres Freund <andres@2ndquadrant.com>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Mike Blackwell <mike.blackwell@rrd.com>, Bruce Momjian <bruce@momjian.us>, Peter Geoghegan <pg@heroku.com>, Claudio Freire <klaussfreire@gmail.com>
Date: 2014-03-04T11:54:05Z
Lists: 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


Commits

  1. Flush stderr and stdout in isolation tester.