On Monday, July 01, 2013 1:36 PM 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.
Thanks, will update the WAL Optimization patch based on this and post the new patch and data on the corresponding thread. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
