Re: Performance Improvement by reducing WAL for Update Operation

On Fri, Dec 6, 2013 at 6:41 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Agreed, summarization of data for LZ/Chunkwise encoding especially for
> non-compressible (hundred tiny fields, all changed/half changed) or less
> compressible data (hundred tiny fields, half nulled) w.r.t CPU
> usage is as below:
>
> a. For hard disk, there is an overhead of 7~16% with LZ delta encoding
> and there is an overhead of 5~8% with Chunk wise encoding.
>
> b. For Tempfs (which means operate on RAM as disk), there is an
> overhead of 19~26%
> with LZ delta encoding and there is an overhead of 9~18% with
> Chunk wise encoding.
>
> There might be some variation of data (in your last mail the overhead
> for chunkwise method for Tempfs was < 12%),
> but in general the data suggests that chunk wise encoding has less
> overhead than LZ encoding for non-compressible data
> and for others it is better or equal.
>
> Now, I think we have below options for this patch:
> a. If the performance overhead for worst case is acceptable (we can
> try to reduce some more, but don't think it will be something
> drastic),
> then this can be done without any flag/option.
> b. Have it with table level option to enable/disable WAL compression
> c. Drop this patch, as for worst cases there is some performance overhead.
> d. Go back and work more on it, if there is any further suggestions
> for improvement.

Based on data posted previously for both approaches
(lz_delta, chunk_wise_encoding) and above options, I have improved
the last version of patch by keeping chunk wise approach and
provided a table level option to user.

Changes in this version of patch:
--------------------------------------------------
1. Implement decoding, it is almost similar to pglz_decompress as
the format to store encoded data is not changed much.

2. Provide a new reloption to specify Wal compression
for update operation on table
Create table tbl(c1 char(100)) With (compress_wal = true);

Alternative options:
a. compress_wal can take input as operation, e.g. 'insert', 'update',
b. use alternate syntax:
Create table tbl(c1 char(100)) Compress Wal For Update;
c. anything better?

3. Fixed below 2 defects in encoding:
a. In function pgrb_find_match(), if last byte of chunk matches,
it consider whole chunk as match.
b. If there is no match, it copies chunk as it is to encoded data,
while copying, it is ignoring last byte.
Due to defect fixes, data can vary, but I don't think there can be
any major change.

Points to consider
-----------------------------

1. As the current algorithm store the entry for same chunks at head of list,
it will always find last but one chunk (we don't store last 4 bytes) for
long matching string during match phase in encoding (pgrb_delta_encode).

We can improve it either by storing same chunks at end of list instead of at
head or by trying to find a good_match technique used in lz algorithm.
Finding good_match technique can have overhead in some of the cases
when there is actually no match.

2. Another optimization that we can do in pgrb_find_match(), is that
currently if
it doesn't find the first chunk (chunk got by hash index) matching, it
continues to find the match in other chunks. I am not sure if there is any
benefit to search for other chunks if first one is not matching.

3. We can move code from pg_lzcompress.c to some new file pg_rbcompress.c,
if we want to move, then we need to either duplicate some common macros
like pglz_out_tag or keep it common, but might be change the name.

4. Decide on min and max chunksize. (currently kept as 2 and 4 respectively).
The point to consider is that if we keep bigger chunk sizes, then it can
save us on CPU cycles, but less reduction in Wal, on the other side if we
keep it small it can have better reduction in Wal but consume more CPU
cycles.

5. kept an guc variable 'wal_update_compression_ratio', for test purpose, we
can remove it before commit.

7. docs needs to be updated, tab completion needs some work.

8. We can extend Alter Table to set compress option for table.

Thoughts/Suggestions?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com