Thank you.
> >heap_attr_get_length_and_check_equals:
..
> >- This function returns always false for attrnum <= 0 as whole
> > tuple or some system attrs comparison regardless of the real
> > result, which is a bit different from the anticipation which
> > the name gives. If you need to keep this optimization, it
> > should have the name more specific to the purpose.
>
> The heap_attr_get_length_and_check_equals function is similar to heap_tuple_attr_equals,
> the attrnum <= 0 check is required for heap_tuple_attr_equals.
Sorry, you're right.
> >haap_delta_encode:
> >
> >- Some misleading variable names (like match_not_found),
> > some reatitions of similiar codelets (att_align_pointer, pglz_out_tag),
> > misleading slight difference of the meanings of variables of
> > similar names(old_off and new_off and the similar pairs),
> > and bit tricky use of pglz_out_add and pglz_out_tag with length = 0.
> >
> > These are welcome to be modified for better readability.
>
> The variable names are modified, please check them once.
>
> The (att_align_pointer, pglz_out_tag) repetition code is added to take care of padding only incase of values are
equal.
> Use of pglz_out_add and pglz_out_tag with length = 0 is done because of code readability.
Oops! Sorry for mistake. My point was that the bases for old_off
(of match_off) and dp, not new_off. It is no unnatural. Namings
had not been the problem and the function was perfect as of the
last patch. I'd been confised by the asymmetry between match_off
to pglz_out_tag and dp to pglz_out_add.
> Another change is also done to handle the history size of 2 bytes which is possible with the usage of LZ macro's for
deltaencoding.
Good catch. This seems to have been a potential bug which does no
harm when called from pglz_compress..
==========
Looking into wal_update_changes_mod_lz_v6.patch, I understand
that this patch experimentally adds literal data segment which
have more than single byte in PG-LZ algorithm. According to
pglz_find_match, memCMP is slower than 'while(*s && *s == *d)' if
len < 16 and I suppose it is probably true at least for 4 byte
length data. This is also applied on encoding side. If this mod
does no harm to performance, I want to see this applied also to
pglz_comress.
By the way, the comment on pg_lzcompress.c:690 seems to quite
differ from what the code does.
regards,
*1: http://archives.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C38285495B0@szxeml509-mbx
--
Kyotaro Horiguchi
NTT Open Source Software Center
