Re: Performance Improvement by reducing WAL for Update Operation

On Thu, Dec 12, 2013 at 12:27 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Thu, Dec 12, 2013 at 3:43 AM, Peter Eisentraut <peter_e@gmx.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