On Mon, Mar 11, 2019 at 10:47 PM Peter Geoghegan <p...@bowt.ie> wrote: > > On Sun, Mar 10, 2019 at 5:17 PM Peter Geoghegan <p...@bowt.ie> wrote: > > The regression that I mentioned earlier isn't in pgbench type > > workloads (even when the distribution is something more interesting > > that the uniform distribution default). It is only in workloads with > > lots of page splits and lots of index churn, where we get most of the > > benefit of the patch, but also where the costs are most apparent. > > Hopefully it can be fixed, but if not I'm inclined to think that it's > > a price worth paying. This certainly still needs further analysis and > > discussion, though. This revision of the patch does not attempt to > > address that problem in any way. > > I believe that I've figured out what's going on here. > > At first, I thought that this regression was due to the cycles that > have been added to page splits, but that doesn't seem to be the case > at all. Nothing that I did to make page splits faster helped (e.g. > temporarily go back to doing them "bottom up" made no difference). CPU > utilization was consistently slightly *higher* with the master branch > (patch spent slightly more CPU time idle). I now believe that the > problem is with LWLock/buffer lock contention on index pages, and that > that's an inherent cost with a minority of write-heavy high contention > workloads. A cost that we should just accept.
If I wanted to try to say this in fewer words, would it be fair to say that reducing the size of an index by 40% without changing anything else can increase contention on the remaining pages? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
