On Wed, Jan 15, 2014 at 7:28 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > Unpatched > ------------------- > testname | wal_generated | > duration > ----------------------------------------------------------+----------------------+------------------ > one short and one long field, no change | 1054923224 | 33.101135969162 > > After pgrb_delta_encoding_v4 > --------------------------------------------- > > testname | wal_generated | > duration > ----------------------------------------------------------+----------------------+------------------ > one short and one long field, no change | 877859144 | 30.6749138832092 > > > Temporary Changes > (Revert Max Chunksize = 4 and logic of finding longer match) > --------------------------------------------------------------------------------------------- > > testname | wal_generated | > duration > ----------------------------------------------------------+----------------------+------------------ > one short and one long field, no change | 677337304 | 25.4048750400543
Sure, but watch me not care. If we're interested in taking advantage of the internal compressibility of tuples, we can do a lot better than this patch. We can compress the old tuple and the new tuple. We can compress full-page images. We can compress inserted tuples. But that's not the point of this patch. The point of *this* patch is to exploit the fact that the old and new tuples are likely to be very similar, NOT to squeeze out every ounce of compression from other sources. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
