Re: Performance Improvement by reducing WAL for Update Operation
От | Heikki Linnakangas |
---|---|
Тема | Re: Performance Improvement by reducing WAL for Update Operation |
Дата | |
Msg-id | 5315AE64.5090504@vmware.com обсуждение исходный текст |
Ответ на | Re: Performance Improvement by reducing WAL for Update Operation (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Performance Improvement by reducing WAL for Update
Operation
Re: Performance Improvement by reducing WAL for Update Operation |
Список | pgsql-hackers |
On 03/03/2014 04:57 PM, Andres Freund wrote: > On 2014-03-03 16:27:05 +0200, Heikki Linnakangas wrote: >> Attached is a rewritten version, which does the prefix/suffix tests directly >> in heapam.c, and adds the prefix/suffix lengths directly as fields in the >> WAL record. If you could take one more look at this version, to check if >> I've missed anything. > > Have you rerun the benchmarks? No. > I'd guess the CPU overhead of this version is lower than earlier > versions, That's what I would expect too. > but seing it tested won't be a bad idea. Agreed. Amit, do you have the test setup at hand, can you check the performance of this one more time? Also, I removed the GUC and table level options, on the assumption that this is cheap enough even when it's not helping that we don't need to make it configurable. >> 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. 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. - Heikki
В списке pgsql-hackers по дате отправления: