Re: [REVIEW] Re: Compression of full-page-writes - Mailing list pgsql-hackers

<p dir="ltr"><br /> Em 26/08/2014 09:16, "Fujii Masao" <<a
href="mailto:masao.fujii@gmail.com">masao.fujii@gmail.com</a>>escreveu:<br /> ><br /> > On Tue, Aug 19, 2014
at6:37 PM, Rahila Syed <<a href="mailto:rahilasyed90@gmail.com">rahilasyed90@gmail.com</a>> wrote:<br /> >
>Hello,<br /> > > Thank you for comments.<br /> > ><br /> > >>Could you tell me where the patch
for"single block in one run" is?<br /> > > Please find attached patch for single block compression in one run.<br
/>><br /> > Thanks! I ran the benchmark using pgbench and compared the results.<br /> > I'd like to share the
results.<br/> ><br /> > [RESULT]<br /> > Amount of WAL generated during the benchmark. Unit is MB.<br />
><br/> >                 Multiple                Single<br /> >     off            202.0               
201.5<br/> >     on            6051.0                6053.0<br /> >     pglz            3543.0               
3567.0<br/> >     lz4            3344.0                3485.0<br /> >     snappy            3354.0               
3449.5<br/> ><br /> > Latency average during the benchmark. Unit is ms.<br /> ><br /> >                
Multiple               Single<br /> >     off            19.1                19.0<br /> >     on            55.3 
             57.3<br /> >     pglz            45.0                45.9<br /> >     lz4            44.2           
   44.7<br /> >     snappy            43.4                43.3<br /> ><br /> > These results show that FPW
compressionis really helpful for decreasing<br /> > the WAL volume and improving the performance.<br /> ><br />
>The compression ratio by lz4 or snappy is better than that by pglz. But<br /> > it's difficult to conclude which
lz4or snappy is best, according to these<br /> > results.<br /> ><br /> > ISTM that
compression-of-multiple-pages-at-a-timeapproach can compress<br /> > WAL more than compression-of-single-...
does.<br/> ><br /> > [HOW TO BENCHMARK]<br /> > Create pgbench database with scall factor 1000.<br /> ><br
/>> Change the data type of the column "filler" on each pgbench table<br /> > from CHAR(n) to TEXT, and fill the
datawith the result of pgcrypto's<br /> > gen_random_uuid() in order to avoid empty column, e.g.,<br /> ><br />
> alter table pgbench_accounts alter column filler type text using<br /> > gen_random_uuid()::text<br /> ><br
/>> After creating the test database, run the pgbench as follows. The<br /> > number of transactions executed
duringbenchmark is almost same<br /> > between each benchmark because -R option is used.<br /> ><br /> >  
pgbench-c 64 -j 64 -r -R 400 -T 900 -M prepared<br /> ><br /> > checkpoint_timeout is 5min, so it's expected that
checkpointwas<br /> > executed at least two times during the benchmark.<br /> ><br /> > Regards,<br /> ><br
/>> --<br /> > Fujii Masao<br /> ><br /> ><br /> > --<br /> > Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> > To make changes to your
subscription:<br/> > <a
href="http://www.postgresql.org/mailpref/pgsql-hackers">http://www.postgresql.org/mailpref/pgsql-hackers</a><p
dir="ltr">It'dbe interesting to check avg cpu usage as well.