On Mon, Jul 1, 2013 at 11:05:37AM +0300, Heikki Linnakangas wrote:
> On 26.06.2013 16:37, Amit Kapila wrote:
> >On Wednesday, June 26, 2013 2:15 AM Heikki Linnakangas wrote:
> >>Can you also try the attached patch, please? It's the same as before,
> >>but in this version, I didn't replace the prev and next pointers in
> >>PGLZ_HistEntry struct with int16s. That avoids some table lookups, at
> >>the expense of using more memory. It's closer to what we have without
> >>the patch, so maybe that helps on your system.
> >
> >Yes it helped a lot on my system.
>
> Ok, good. Strange, I did not expect such a big difference.
>
> >There was minor problem in you patch, in one of experiments it crashed.
> >Fix is not to access 0th history entry in function pglz_find_match(),
> >modified patch is attached.
>
> Thanks, good catch! I thought that a pointer to the 0th entry would
> never make it into the prev/next fields, but it does. In fact, we
> never store a NULL there anymore, a pointer to the 0th entry is now
> always used to mean 'invalid'. I adjusted the patch to remove the
> NULL check, and only check for the 0th entry.
>
> Committed.
Does someone have new tests comparing this patch with the new
compression methods being considered?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +