Re: CLUSTER FREEZE

From: Thom Brown <thom(at)linux(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Thomas Munro <munro(at)ip9(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLUSTER FREEZE
Date: 2013-10-24 08:15:10
Message-ID: CAA-aLv5sZxFvrVWx8YLSHnDKXeBuM+=rLSR7LsqiGTW1F1FCRQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24 October 2013 05:58, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Oct 24, 2013 at 4:58 AM, Thomas Munro <munro(at)ip9(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-10-24 08:18:04 Re: CLUSTER FREEZE
Previous Message Abhijit Menon-Sen 2013-10-24 06:06:51 Re: [PATCH] Use MAP_HUGETLB where supported (v3)