Re: [HACKERS] GUC for cleanup indexes threshold.
| От | Darafei "Komяpa" Praliaskouski |
|---|---|
| Тема | Re: [HACKERS] GUC for cleanup indexes threshold. |
| Дата | |
| Msg-id | CAC8Q8tJCb=gxhzcV7T6ctx7PY-Ux1oA-AsTJc6cAVNsQiYcCzA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] GUC for cleanup indexes threshold. (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
| Ответы |
Re: [HACKERS] GUC for cleanup indexes threshold.
|
| Список | pgsql-hackers |
Hi!
It is cool to see this in Postgres 11. However:
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 oftable 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"?
В списке pgsql-hackers по дате отправления: