On Tue, Feb 21, 2017 at 4:21 PM, Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > > Hi, Ashutosh! > On Mon, Feb 20, 2017 at 1:20 PM, Ashutosh Sharma <ashu.coe...@gmail.com> > wrote: >> >> Following are the pgbench results for read-write workload, I got with >> pgxact-align-3 patch. The results are for 300 scale factor with 8GB of >> shared buffer i.e. when data fits into the shared buffer. For 1000 scale >> factor with 8GB shared buffer the test is still running, once it is >> completed I will share the results for that as well. >> >> pgbench settings: >> pgbench -i -s 300 postgres >> pgbench -M prepared -c $thread -j $thread -T $time_for_reading postgres >> >> where, time_for_reading = 30mins >> >> non default GUC param: >> shared_buffers=8GB >> max_connections=300 >> >> pg_xlog is located in SSD. > > > Thank you for testing. > It seems that there is still regression. While padding was reduced from 116 > bytes to 4 bytes, it makes me think that probably there is something wrong in > testing methodology. > Are you doing re-initdb and pgbench -i before each run? I would ask you to > do the both. > Also, if regression would still exist, let's change the order of versions. > Thus, if you run master before patched version, I would ask you to run > patched version before master.
Yes, there is still some regression however it has come down by a small margin. I am not doing initdb for each run instead I am doing, dropdb-->createdb-->pgbench -i. Is dropping old database and creating a new one for every run not okay, Do I have to do initdb every time. Okay, I can change the order of reading and let you know the results. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
