Re: CLUSTER FREEZE - Mailing list pgsql-hackers

From Thom Brown
Subject Re: CLUSTER FREEZE
Date
Msg-id CAA-aLv5sZxFvrVWx8YLSHnDKXeBuM+=rLSR7LsqiGTW1F1FCRQ@mail.gmail.com
Whole thread Raw
In response to Re: CLUSTER FREEZE  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 24 October 2013 05:58, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro <munro@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?

Well I can't speak for Thomas, but if you're doing such a heavy-duty
operation on a table that involves an exclusive lock, you may as well
freeze it.  And in the case of CLUSTER, I imagine that in most
instances you'd be confident the table isn't going to undergo much
change (or at least not quickly).  CLUSTER FREEZE would mean not
having to run a separate VACUUM FREEZE after, and on a 10GB table,
that's a big deal as it means not having to rescan the whole table
again to freeze every row.

Note that REFRESH MATERIALIZED VIEW freezes rows too as it's already
writing all the data from scratch again, and has an exclusive lock.
(this isn't the case with the CONCURRENTLY option obviously)

-- 
Thom



pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Next
From: Andres Freund
Date:
Subject: Re: CLUSTER FREEZE