On Tue, Oct 23, 2018 at 11:35 AM Andrey Lepikhov <a.lepik...@postgrespro.ru> wrote: > I have same problem with background heap & index cleaner (based on your > patch). In this case the bottleneck is WAL-record which I need to write > for each cleaned block and locks which are held during the WAL-record > writing process.
Part of the problem here is that v6 uses up to 25 candidate split points, even during regularly calls to _bt_findsplitloc(). That was based on some synthetic test-cases. I've found that I can get most of the benefit in index size with far fewer spilt points, though. The extra work done with an exclusive buffer lock held will be considerably reduced in v7. I'll probably post that in a couple of weeks, since I'm in Europe for pgConf.EU. I don't fully understand the problems here, but even still I know that what you were testing wasn't very well optimized for write-heavy workloads. It would be especially bad with pgbench, since there isn't much opportunity to reduce the size of indexes there. > Maybe you will do a test without writing any data to disk? Yeah, I should test that on its own. I'm particularly interested in TPC-C, because it's a particularly good target for my patch. I can find a way of only executing the read TPC-C queries, to see where they are on their own. TPC-C is particularly write-heavy, especially compared to the much more recent though less influential TPC-E benchmark. -- Peter Geoghegan
