Re: Optimizing pglz compressor
От | Bruce Momjian |
---|---|
Тема | Re: Optimizing pglz compressor |
Дата | |
Msg-id | 20130701165138.GC16348@momjian.us обсуждение исходный текст |
Ответ на | Re: Optimizing pglz compressor (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | pgsql-hackers |
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. +
В списке pgsql-hackers по дате отправления: