Re: Multiple FPI_FOR_HINT for the same block during killing btreeindex items
От | Peter Geoghegan |
---|---|
Тема | Re: Multiple FPI_FOR_HINT for the same block during killing btreeindex items |
Дата | |
Msg-id | CAH2-Wz=ANZ4tAnr6CjLXrkvsZs29KqfHaTGZ_T_+3dWPVtnpuQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Multiple FPI_FOR_HINT for the same block during killing btreeindex items (James Coleman <jtc331@gmail.com>) |
Ответы |
Re: Multiple FPI_FOR_HINT for the same block during killing btreeindex items
|
Список | pgsql-hackers |
On Thu, Apr 9, 2020 at 1:37 PM James Coleman <jtc331@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
В списке pgsql-hackers по дате отправления: