RE: reloption to prevent VACUUM from truncating empty pages at theend of relation - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: reloption to prevent VACUUM from truncating empty pages at theend of relation
Date
Msg-id 0A3221C70F24FB45833433255569204D1FBBB922@G01JPEXMBYT05
Whole thread Raw
In response to Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses 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>)
List 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 by date:

Previous
From: Sergei Kornilov
Date:
Subject: Re: Prevent extension creation in temporary schemas
Next
From: "Imai, Yoshikazu"
Date:
Subject: RE: Problem with default partition pruning