On Mon, Dec 2, 2013 at 7:40 PM, Haribabu kommi
<haribabu.kommi@huawei.com> wrote:
> On 29 November 2013 03:05 Robert Haas wrote:
>> On Wed, Nov 27, 2013 at 9:31 AM, Amit Kapila <amit.kapila16@gmail.com>
>> wrote:
>
> I tried modifying the existing patch to support the dynamic rollup as follows.
> For every 32 bytes mismatch between the old and new tuple and it resets back whenever it found a match.
>
> 1. pglz-with-micro-optimization-compress-using-newdata-5:
>
> Adds all old tuple data to history and then check for the match from new tuple.
> For every 32 bytes mismatch, it checks for the match for 2 bytes once. Like this
> It repeats until it found a match or end of data.
>
> 2. pglz-with-micro-optimization-compress-using-newdata_snappy_hash-1:
>
> Adds only first byte of old tuple data to the history and then check for the match
> From new tuple. If any match found, then next unmatched byte from old tuple is added
> To the history and repeats the process.
>
> If no match founds then adds the next byte of the old tuple history followed by the
> Unmatched byte from new tuple data to the history.
>
> In this case the performance is good, but if there is any forward references in the
> New data with old data then it will not compress the data.
The performance data has still same problem that is on fast disks
(tempfs data) it is low.
I am already doing chunk-wise implementation to see if it can improve
the situation, please wait
and then we can decide what is the best way to proceed.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com