Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: reloption to prevent VACUUM from truncating empty pages at theend of relation |
| Дата | |
| Msg-id | 20190225092507.GG30864@paquier.xyz обсуждение |
| Ответ на | Re: reloption to prevent VACUUM from truncating empty pages at theend of relation (Julien Rouhaud <rjuju123@gmail.com>) |
| Ответы |
Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
|
| Список | pgsql-hackers |
On Mon, Feb 25, 2019 at 08:47:28AM +0100, Julien Rouhaud wrote:
> Ah good point. We could also use something like
> pg_relation_size('reloptions_test') /
> current_setting('block_size')::bigint but >0 should be enough for this
> test.
Also, shouldn't the relopt check happen in
should_attempt_truncation()? It seems to me that if we use this
routine somewhere else then it should be controlled by the option.
At the same time, we also have REL_TRUNCATE_FRACTION and
REL_TRUNCATE_MINIMUM which could be made equally user-tunnable.
That's more difficult to control, still why don't we also consider
this part?
Another thing that seems worth thinking about is a system-level GUC,
and an option in the VACUUM command to control if truncation should
happen or not. We have a lot of infrastructure to control such
options between vacuum and autovacuum, so it could be a waste to not
consider potential synergies.
--
Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера