On 2013-10-25 09:13:20 -0400, Robert Haas wrote: > On Fri, Oct 25, 2013 at 2:12 AM, Andres Freund <and...@2ndquadrant.com> wrote: > > On 2013-10-24 17:17:22 -0700, Josh Berkus wrote: > >> On 10/24/2013 04:55 PM, Robert Haas wrote: > >> > On Thu, Oct 24, 2013 at 1:09 PM, Josh Berkus <j...@agliodbs.com> wrote: > >> >> On 10/23/2013 09:58 PM, Amit Kapila wrote: > >> >>> 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? > >> >> > >> >> "If I'm rewriting the table anyway, let's freeze it". > >> >> > >> >> Otherwise, you have to write the same pages twice, if both CLUSTER and > >> >> FREEZE are required. > >> > > >> > I wonder if we should go so far as to make this the default behavior, > >> > instead of just making it an option. > >> > >> +1 from me. Can you think of a reason you *wouldn't* want to freeze? > > > > It makes content from the future appear when you start using the > > relation in a query/session with an older snapshot. Currently CLUSTER is > > safe against that. > > Eh, what? We wouldn't freeze XIDs that don't precede RecentGlobalXmin.
Ah sorry, I thought that'd be the plan, similar to COPY FREEZE. Maybe because I've wished for it in the past ;) In that case I agree it should be the default. There really isn't any reason to not to immediately freeze tuples that can be frozen according to the xmin horizon. We don't immediately do it during normal vacuums because it would possibly cause superflous io - but that's not the case here. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
