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
-
Flush stderr and stdout in isolation tester.
- 63d283ecd0bc 9.3.0 cited