From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com> |
Subject: | Re: Performance Improvement by reducing WAL for Update Operation |
Date: | 2014-01-15 19:19:59 |
Message-ID: | CA+TgmoYT_G3vxBoCJB9Y=CjbKNP8ky7Oo7+EQueOWj7Tm_PxDQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 15, 2014 at 7:28 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2014-01-15 19:40:25 | Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it |
Previous Message | Stephen Frost | 2014-01-15 19:10:23 | Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it |