Re: vacuum -vs reltuples on insert only index
От | Peter Geoghegan |
---|---|
Тема | Re: vacuum -vs reltuples on insert only index |
Дата | |
Msg-id | CAH2-WzkN7ofNX_99q3w44vDqaz=CRNmSF5V7R7yWrHfmprRX-A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: vacuum -vs reltuples on insert only index (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: vacuum -vs reltuples on insert only index
Re: vacuum -vs reltuples on insert only index |
Список | pgsql-hackers |
On Fri, Oct 23, 2020 at 11:10 AM Peter Geoghegan <pg@bowt.ie> wrote: > I suspect that we need to move in this direction within nbtree. I'm a > bit concerned about the partial index problem, though. I suppose maybe > we could do it the old way (which won't account for posting list > tuples) during cleanup as you suggest, but only use the final figure > when it turns out to have been a partial indexes. For other indexes we > could do what GIN does here. Actually, it seems better to always count num_index_tuples the old way during cleanup-only index VACUUMs, despite the inaccuracy that that creates with posting list tuples. The inaccuracy is at least a fixed and relatively small inaccuracy, since nbtree doesn't have posting list compression or a pending list mechanism (unlike GIN). This approach avoids calculating a num_index_tuples value that is less than the number of distinct values in the index, which seems important. Taking a more sophisticated approach seems unnecessary, especially given that we need something that can be backpatched to Postgres 13. Attached is my proposed fix, which takes this approach. I will commit this on Wednesday or Thursday, barring any objections. Thanks -- Peter Geoghegan
Вложения
В списке pgsql-hackers по дате отправления: