On Thu, Jan 16, 2014 at 12:07 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Jan 16, 2014 at 12:49 AM, Robert Haas <robertmh...@gmail.com> wrote: >> 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. > > Okay, got your point. > Another minor thing is that in latest patch which I have sent yesterday, > I have modified it such that while formation of chunks if there is a data > at end of string which doesn't have special pattern and is less than max > chunk size, we also consider that as a chunk. The reason of doing this > was that let us say if we have 104 bytes string which contains no special > bit pattern, then it will just have one 64 byte chunk and will leave the > remaining bytes, which might miss the chance of doing compression for > that data.
Yeah, that sounds right. -- 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
