Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM |
| Дата | |
| Msg-id | YBO13CG6m9QB91oy@paquier.xyz обсуждение |
| Ответ на | Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM ("Bossart, Nathan" <bossartn@amazon.com>) |
| Ответы |
Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM
|
| Список | pgsql-hackers |
On Thu, Jan 28, 2021 at 06:16:09PM +0000, Bossart, Nathan wrote: > I chose TOAST_TABLE_CLEANUP to match the INDEX_CLEANUP option, but I'm > not wedded to that name. What do you think about PROCESS_TOAST_TABLE? Most of the other options use a verb, so using PROCESS, or even SKIP sounds like a good idea. More ideas: PROCESS_TOAST, SKIP_TOAST. I don't like much the term CLEANUP here, as it may imply, at least to me, that the toast relation is getting partially processed. > IMO we should emit an ERROR in this case. If we ignored it, we'd end > up processing the TOAST table even though the user asked us to skip > it. Issuing an error makes the most sense to me per the argument based on cluster_rel() and copy_table_data(). Silently ignoring options can be confusing for the end-user. + <para> + Do not clean up the TOAST table. + </para> Is that enough? I would say instead: "Skip the TOAST table associated to the table to vacuum, if any." -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера