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 0A3221C70F24FB45833433255569204D1FBBA486@G01JPEXMBYT05
Whole thread Raw
In response to Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
From: Robert Haas [mailto:robertmhaas@gmail.com]
> I don't think that a VACUUM option would be out of place, but a GUC
> sounds like an attractive nuisance to me.  It will encourage people to
> just flip it blindly instead of considering the particular cases where
> they need that behavior, and I think chances are good that most people
> who do that will end up being sad.

Ouch, I sent my previous mail before reading this.  I can understand it may be cumbersome to identify and specify each
table,so I tend to agree the parameter in postgresql, which is USERSET to allow ALTER DATABASE/USER SET to tune
specificdatabases and applications.  But should the vacuuming of system catalogs also follow this setting?
 


Regards
Takayuki Tsunakawa



pgsql-hackers by date:

Previous
From: Marc Dean
Date:
Subject: Re: BUG #15293: Stored Procedure Triggered by Logical Replication isUnable to use Notification Events
Next
From: Michael Paquier
Date:
Subject: Re: pg_partition_tree crashes for a non-defined relation