On 4 January 2013 13:53, Amit Kapila <amit.kap...@huawei.com> wrote: > On Friday, December 28, 2012 3:52 PM Simon Riggs wrote: >> On 28 December 2012 08:07, Kyotaro HORIGUCHI >> <horiguchi.kyot...@lab.ntt.co.jp> wrote: >> >> > Hello, I saw this patch and confirmed that >> > >> > - Coding style looks good. >> > - Appliable onto HEAD. >> > - Some mis-codings are fixed. >> >> I've had a quick review of the patch to see how close we're getting. >> The perf tests look to me like we're getting what we wanted from this >> and I'm happy with the recovery performance trade-offs. Well done to >> both author and testers. >> >> >> * The compression algorithm depends completely upon new row length >> savings. If the new row is short, it would seem easier to just skip >> the checks and include it anyway. We can say if old and new vary in >> length by > 50% of each other, just include new as-is, since the rows >> very clearly differ in a big way. > >> Also, if tuple is same length as >> before, can we compare the whole tuple at once to save doing >> per-column checks? > > If we have to do whole tuple comparison then storing of changed parts might > need to be > be done in a byte-by-byte way rather then at column offset boundaries. > This might not be possible with current algorithm as it stores in WAL > information column-by-column and decrypts also in similar way.
OK, please explain in comments. >> The internal docs are completely absent. We need at least a whole page of > descriptive > comment, discussing trade-offs and design decisions. > > Currently I have planned to put it transam/README, as most of WAL > description is present there. But also in comments for each major function. Thanks -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers