On Thu, Mar 23, 2017 at 12:19 AM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > > Ok, no problem. I did some tests on AWS i2.xlarge instance (4 vCPU, 30GB > RAM, attached SSD) and results are shown below. But I think it is important > to get independent validation from your side too, just to ensure I am not > making any mistake in measurement. I've attached naively put together > scripts which I used to run the benchmark. If you find them useful, please > adjust the paths and run on your machine. > > I reverted back to UNLOGGED table because with WAL the results looked very > weird (as posted earlier) even when I was taking a CHECKPOINT before each > set and had set max_wal_size and checkpoint_timeout high enough to avoid any > checkpoint during the run. Anyways, that's a matter of separate > investigation and not related to this patch. > > I did two kinds of tests. > a) update last column of the index > b) update second column of the index > > v19 does considerably better than even master for the last column update > case and pretty much inline for the second column update test. The reason is > very clear because v19 determines early in the cycle that the buffer is > already full and there is very little chance of doing a HOT update on the > page. In that case, it does not check any columns for modification. >
That sounds like you are dodging the actual problem. I mean you can put that same PageIsFull() check in master code as well and then you will most probably again see the same regression. Also, I think if we test at fillfactor 80 or 75 (which is not unrealistic considering an update-intensive workload), then we might again see regression. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
