On Thu, Apr 9, 2020 at 1:37 PM James Coleman <jtc...@gmail.com> wrote: > We saw the issue on our PG11 clusters. The specific index we noticed > in the wal dump (I don't think we confirmed if there were others) as > one on a `created_at` column, to give you an idea of cardinality.
You tend to get a lot of problems with indexes like that when there are consistent updates (actually, that's more of a thing with an updated_at index). But non-HOT updates alone might result in what you could describe as "updates" to the index. With Postgres 11, a low cardinality index could place new/successor duplicate index tuples (those needed for non-HOT updates) on a more or less random leaf page (you'll recall that this is determined by the old "getting tired" logic). This is the kind of thing I had in mind when I asked Sawada-san about it. Was this a low cardinality index in the way I describe? If it was, then we can hope (and maybe even verify) that the Postgres 12 work noticeably ameliorates the problem. -- Peter Geoghegan
