RE: reloption to prevent VACUUM from truncating empty pages at theend of relation

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема RE: reloption to prevent VACUUM from truncating empty pages at theend of relation
Дата
Msg-id 0A3221C70F24FB45833433255569204D1FBBB922@G01JPEXMBYT05
обсуждение исходный текст
Ответ на Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Laurenz Albe <laurenz.albe@cybertec.at>)
Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
From: Alvaro Herrera [mailto:alvherre@2ndquadrant.com]
> Robert used the phrase "attractive nuisance", which maybe sounds like a
> good thing to have to a non native speaker, but it actually isn't -- he
> was saying we should avoid a GUC at all, and I can see the reason for
> that.  I think we should have a VACUUM option and a reloption, but no
> GUC.

Uh, thanks.  I've just recognized I didn't know the meaning of "nuisance."  I've looked up the meaning in the
dictionary. Nuisance is like a trouble maker...
 

Why do you think that it's better for VACUUM command to have the option?  I think it's a table property whose value is
determinedbased on the application workload, not per VACUUM execution.  Rather, I think GUC is more useful to determine
thebehavior of the entire database and/or application.
 

If we want to change a given execution of VACUUM, then we can ALTER TABLE SET, VACUUM, and ALTER TABLE SET back.


Regards
Takayuki Tsunakawa



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sergei Kornilov
Дата:
Сообщение: Re: Prevent extension creation in temporary schemas
Следующее
От: "Imai, Yoshikazu"
Дата:
Сообщение: RE: Problem with default partition pruning