Re: Using COPY FREEZE in pgbench - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Using COPY FREEZE in pgbench
Date
Msg-id 20210322.092254.1765947490717657568.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: Using COPY FREEZE in pgbench  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Using COPY FREEZE in pgbench  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: Using COPY FREEZE in pgbench  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
> I did a few tests on my laptop. Is seems that copying takes a little
> more time, say about 10%, but vacuum is indeed very significantly
> reduced, so that the total time for copying and vacuuming is reduced
> by 10% on overall.
> 
> So it is okay for me.

Thanks for the test.

I wrote:
> Curent master:
> pgbench -i -s 100
> :
> :
> done in 70.78 s (drop tables 0.21 s, create tables 0.02 s, client-side generate 12.42 s, vacuum 51.11 s, primary keys
7.02s).
 
> 
> Using FREEZE:
> done in 16.86 s (drop tables 0.20 s, create tables 0.01 s, client-side generate 11.86 s, vacuum 0.25 s, primary keys
4.53s).
 
> 
> As you can see total time drops from 70.78 seconds to 16.86 seconds,
> that is 4.1 times faster. This is mainly because vacuum takes only
> 0.25 seconds after COPY FREEZE while unpatched pgbench takes 51.11
> seconds, which is 204 times slower.

I did same test again.

13.2 pgbench + master branch server:
done in 15.47 s (drop tables 0.19 s, create tables 0.01 s, client-side generate 9.07 s, vacuum 2.07 s, primary keys
4.13s).
 

With patch on master branch:
done in 13.38 s (drop tables 0.19 s, create tables 0.01 s, client-side generate 9.68 s, vacuum 0.23 s, primary keys
3.27s).
 

This time current pgbench performs much faster than I wrote (15.47 s
vs. 70.78 s). I don't why.

Anyway, this time total pgbench time is reduced by 14% over all
here. I hope people agree that the patch is worth the gain.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Why logical replication lancher exits 1?
Next
From: ikedamsh
Date:
Subject: Re: About to add WAL write/fsync statistics to pg_stat_wal view