Re: CLUSTER FREEZE - Mailing list pgsql-hackers

From Robert Haas
Subject Re: CLUSTER FREEZE
Date
Msg-id CA+TgmoYGMz0Zh_WtNAk3V1xJhRfsa7sqWBNxRitd8YBRs42+sg@mail.gmail.com
Whole thread Raw
In response to Re: CLUSTER FREEZE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CLUSTER FREEZE  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Thu, Oct 24, 2013 at 10:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I wonder if we should go so far as to make this the default behavior,
>> instead of just making it an option.
>
> In that case you'd have to invent a NOFREEZE keyword, no?  Ick.

Only if we think anyone would ever NOT want to freeze.

> In any case, it's very far from obvious to me that CLUSTER ought
> to throw away information by default, which is what you're proposing.

I find it odd to referring to this as throwing away information.  I
know that you have a general concern about throwing away XIDs that are
still needed for forensic purposes, but that is clearly the ONLY
purpose that those XIDs serve, and the I/O advantages of freezing by
default could be massive for many of our users.  What's going to
happen in practice is that experienced users will simply recommend
CLUSTER FREEZE rather than plain CLUSTER, and you won't have the
forensic information *anyway*.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: CLUSTER FREEZE
Next
From: Robert Haas
Date:
Subject: Re: UNION ALL on partitioned tables won't use indices.