On Fri, Oct 25, 2013 at 4:29 AM, Thomas Munro <mu...@ip9.org> wrote: > On 24 October 2013 05:58, Amit Kapila <amit.kapil...@gmail.com> wrote: >> >> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro <mu...@ip9.org> wrote: >> > Hi >> > I noticed that CLUSTER doesn't have a FREEZE option. Here is a patch to >> > add >> > that, for consistency with VACUUM. Is it useful? >> >> I wonder why anyone would like to freeze during CLUSTER command when >> they already have separate way (VACUUM FREEZE) to achieve it, do you >> know or can think of any case where user wants to do it along with >> Cluster command? > > > As others have said, the goal is to freeze and cluster in a single step. > You can already do that if you know how things work under the covers with: > > SET vacuum_freeze_min_age = 0; > CLUSTER my_table;
True, but in that case why don't we just mention above in the documentation of CLUSTER command, so that if user wants to freeze along with Cluster, he can use above way to Cluster. Some of the reason's, I could think of adding FREEZE as an option are: a. it's more explicit and easy to use for user. b. if by chance underlying mechanism changes (which is less likely) then above way of doing Cluster might not result into freeze. > This patch lets you say CLUSTER FREEZE instead. It mirrors VACUUM, which > can freeze tuples based on the GUC and tuple age or the FREEZE keyword. > >> >> Anyway code side, I think you need to set both feeze_min_age as well >> as freeze_table_age, see VACUUM command in gram.y > > > Ok, I attach a new version that is more like VACUUM in gram.y. (Although > I'm not sure why it isn't a single boolean flag). The reason of separate flags is that both are used to decide different things, freeze_min_age - this is used to decide the cutoff_xid, based on which FrozenTransactionId will be placed on tuple. freeze_table_age - used do decide, whether to scan all pages of a relation in Vacuum and in Cluster command it is ignored as it needs to scan all pages anyway. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
