On Fri, Mar 2, 2018 at 1:35 PM, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > > Hello Amit, > >> At EnterpriseDB, we (me and some of my colleagues) are working from more >> than a year on the new storage format in which only the latest version of >> the data is kept in main storage and the old versions are moved to an undo >> log. [...] > > > This looks more than great! >
Thanks. >> *We’ve shown the performance improvement of zheap over heap in a few >> different pgbench scenarios. [...] > > >> 2. Transaction aborts will be expensive. > > > ISTM that some scenarii should also test the performance impact when the > zheap storage is expected to be worse than the heap storage, i.e. with some > rollback which will exercise the undo stuff. There does not seem to be any > in your report, I apologise if I misread it. > No, there isn't any. One idea, we have to mitigate this cost is to allow rollbacks to happen in the background. Currently, the patch for the same is being worked upon. > I would suggest that you can use pgbench scripts such as: > > -- commit.sql > \set aid random(1, 100000 * :scale) > BEGIN; > UPDATE pgbench_accounts > SET abalance = abalance + 1 > WHERE aid = :aid; > COMMIT; > > and > > -- rollback.sql > \set aid random(1, 100000 * :scale) > BEGIN; > UPDATE pgbench_accounts > SET abalance = abalance + 1 > WHERE aid = :aid; > ROLLBACK; > > that can run with various weights to change how much rollback is injected, > eg 1% rollback rate is achieved with: > > pgbench -T 10 -P 1 -M prepared -r \ > -f SQL/commit.sql@99 -f SQL/rollback.sql@1 > > Also, I would be wary of doing only max speed test, and consider more > realistic --rate tests where the tps is fixed. > Your suggestions are good, we will try to do some tests based on these ideas after making some more progress in the Rollbacks (there is some pending work in Rollbacks as mentioned in README.md). -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
