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  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to