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
