On Wednesday, October 03, 2012 9:33 PM Amit Kapila wrote:
On Friday, September 28, 2012 7:03 PM Amit Kapila wrote:
> > On Thursday, September 27, 2012 6:39 PM Amit Kapila wrote:
> > > On Thursday, September 27, 2012 4:12 PM Heikki Linnakangas wrote:
> > > On 25.09.2012 18:27, Amit Kapila wrote:
> > > > If you feel it is must to do the comparison, we can do it in same
> > way
> > > > as we identify for HOT?
> > >
>
>
> > Now I shall do the various tests for following and post it here:
> > a. Attached Patch in the mode where it takes advantage of history
> > tuple b. By changing the logic for modified column calculation to use
> > calculation for memcmp()
>
>
> 1. Please find the results (pgbench_test.htm) for point -2 where there is
> one fixed column updation (last few bytes are random) and second column
> updation is 32 byte random string. The results for 50, 100 are still going
> on others are attached with this mail.
The results for updated record size (50,100) is attached with this mail
Observations
a. The performance is comparable for both approaches
>> 4. Complete testing for LZ compression patch using testcases defined for
>> original patch
> a. During testing of LZ patch, few issues are found related to when the updated record contains NULLS. Working
onit to fix.
The problems were that
a. offset calculation during compression is based on input buffer [new tuple] and oldtuple [history]. Offset
shouldbe relative to history end.
In normal LZ compression always input buffer and history will be adjacent, so there is no problem for it.
b. The new tuple contents should not be added to history buffer as the addresses will be different for new tuple
andhistory. So it will make offset
calculation go wrong.
Patch containing fix of above problems is attached with this mail.
With Regards,
Amit Kapila.
