On Mon, Jul 9, 2018 at 9:43 AM, Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > In this case it also looks like we observed 1% regression. Despite 1% > may seem to be very small, I think we should clarify whether it really > exists. I have at least two hypothesis about this. > > 1) There is no real regression, observed difference of TPS is less > than error of measurements. In order to check that we need to retry > the experiment multiple times. Also, if you run benchmark on master > before patched version (or vice versa) you should also try to swap the > order to make sure there is no influence of the order of benchmarks. > 2) If we consider relation between TPS and number of clients, TPS is > typically growing with increasing number of clients until reach some > saturation value. After the saturation value, there is some > degradation of TPS. If patch makes some latency lower, that my cause > saturation to happen earlier. In order to check that, we need run > benchmarks with various number of clients and draw a graph: TPS > depending on clients. > > So, may I ask you to make more experiments in order to clarify the > observed regression?
It would be nice to actually see script_duplicated.sql. I don't know exactly what the test case was. Here is my wild guess: You may end up moving right more often within _bt_findinsertloc(), which is actually worse than moving right within _bt_moveright(), even when you _bt_moveright() in exclusive mode. _bt_findinsertloc() couples/crabs exclusive buffer locks because the unique case requires it, even when we're not inserting into a unique index. Whereas _bt_moveright() holds at most one buffer lock at a time. -- Peter Geoghegan