On Sun, Mar 7, 2021 at 8:52 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > Yeah, I think that's right. > > Perhaps we can do something so that autovacuums triggered by > autovacuum_vacuum_insert_scale_factor are triggered on only a true > insert-only case (e.g., by checking if n_dead_tup is 0).
Right -- that's really what it would mean to "remove vacuum_cleanup_index_scale_factor in the backbranches". I now think that it won't even be necessary to make many changes within VACUUM ANALYZE to avoid unwanted side-effects from removing vacuum_cleanup_index_scale_factor, per my mail to Tom today: https://postgr.es/m/cah2-wzknxdcomjhqo4suxvfk_q1171gjo2zghz1y6pion6u...@mail.gmail.com I'm starting to lean towards "removing vacuum_cleanup_index_scale_factor" in Postgres 13 and master only, purely to fix the two issues in Postgres 13 (the insert-driven vacuum issue and the deduplication stats issue I go into in the mail I link to). A much more conservative approach should be used to fix the more superficial issue -- the issue of getting an accurate value (for pg_class.teltuples) from "info->num_heap_tuples". As discussed already, the conservative fix is to delay reading "info->num_heap_tuples" until btvacuumcleanup(), even in cases where there are btbulkdelete() calls for the VACUUM. Then we can then revisit your patch to make vacuumlazy.c skip index vacuuming when there are very few dead tuples, but more than 0 dead tuples [1]. I should be able to commit that for Postgres 14. (I will probably finish off my other patch to make nbtree VACUUM recycle pages deleted during the same VACUUM operation last of all.) [1] https://postgr.es/m/CAD21AoAtZb4+HJT_8RoOXvu4HM-Zd4HKS3YSMCH6+-W=bdy...@mail.gmail.com -- Peter Geoghegan
