Re: Performance Improvement by reducing WAL for Update Operation

On Thu, Dec 12, 2013 at 12:27 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Dec 12, 2013 at 3:43 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> This patch fails the regression tests; see attachment.
>
> Thanks for reporting the diffs. The reason for failures is that
> still decoding for tuple is not done as mentioned in Notes section in
> mail
> (http://www.postgresql.org/message-id/CAA4eK1JeUbY16uwrDA2TaBkk+rLRL3Giyyqy1mVh_6CThmDR8w@mail.gmail.com)
>
> However, to keep the sanity of patch, I will do that and post an
> updated patch, but I think the main idea behind new approach at this
> point is to get feedback on if such an optimization is acceptable
> for worst case scenarios and if not whether we can get this done
> with table level or GUC option.

I don't understand why lack of decoding support should cause
regression tests to fail. I thought decoding was only being done
during WAL replay, a case not exercised by the regression tests.

A few other comments:

+#define PGRB_HKEY_PRIME 11 /* prime number used for
rolling hash */
+#define PGRB_HKEY_SQUARE_PRIME 11 * 11 /* prime number
used for rolling hash */
+#define PGRB_HKEY_CUBE_PRIME 11 * 11 * 11 /* prime
number used for rolling hash */

11 * 11 can't accurately be described as a prime number. Nor can 11 *
11 * 11. Please adjust the comment. Also, why 11?

It doesn't appear that pglz_hist_idx is changed except for whitespace;
please revert that hunk.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company