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. > 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. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
