Hi! It is cool to see this in Postgres 11. However:
> 4) vacuum_cleanup_index_scale_factor can be set either by GUC or > reloption. > Default value is 0.1. So, by default cleanup scan is triggered after > increasing of > table size by 10%. > vacuum_cleanup_index_scale_factor can be set to the maximum of 100. I imagine that on a large append-only table with IOPS storage system budget it may happen that I would want to never perform a full scan on index. Roughly, with parameter set to 100, if we vacuum the table first time with 1 tuple and 130 byte wide rows, we'll have a full scan at 130 bytes, 12 kbytes, 1.2MB, 123MB, 12 GB, 1.2TB. If we happen to perform the first vacuum when there are 4 tuples in the table, it becomes 52kb, 5MB, 495MB, 48GB - and both 12GB and 48GB will exhaust any storage spike IOPS budget, slowing everything down rather suddenly. Can the upper limit for this GUC be lifted, or have a value for "never"?
