On Mon, Mar 11, 2019 at 10:47 PM Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Sun, Mar 10, 2019 at 5:17 PM Peter Geoghegan <pg@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
