On Thu, 22 Oct 2020 at 18:42, Peter Geoghegan <p...@bowt.ie> wrote: > > The average latency is x2. What is the distribution of latencies? > > Occasional very long or all uniformly x2? > > The latency is generally very even with the patch. There is a constant > hum of cleanup by the new mechanism in the case of the benchmark > workload. As opposed to a cascade of page splits, which occur in > clearly distinct correlated waves.
Please publish details of how long a pre-split cleaning operation takes and what that does to transaction latency. It *might* be true that the cost of avoiding splits is worth it in balance against the cost of splitting, but it might not. You've shown us a very nice paper analysing the page split waves, but we need a similar detailed analysis so we can understand if what you propose is better or not (and in what situations). > > I would guess that holding the page locks will also slow down SELECT > > workload, so I think you should also report that workload as well. > > > > Hopefully that will be better in the latest version. > > But the same benchmark that you're asking about here has two SELECT > statements and only one UPDATE. It already is read-heavy in that > sense. And we see that the latency is also significantly improved for > the SELECT queries. > > Even if there was often a performance hit rather than a benefit (which > is definitely not what we see), it would still probably be worth it. > Users create indexes for a reason. I believe that we are obligated to > maintain the indexes to a reasonable degree, and not just when it > happens to be convenient to do so in passing. The leaf page locks are held for longer, so we need to perform sensible tests that show if this has a catastrophic effect on related workloads, or not. The SELECT tests proposed need to be aimed at the same table, at the same time. > The strength of the design is in how clever it isn't. What it doesn't do could be good or bad so we need to review more details on behavior. Since the whole idea of the patch is to change behavior, that seems a reasonable ask. I don't have any doubt about the validity of the approach or coding. What you've done so far is very good and I am very positive about this, well done. -- Simon Riggs http://www.EnterpriseDB.com/