Re: Making table reloading easier

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Making table reloading easier
Date: 2016-11-03 23:47:26
Message-ID: CAB7nPqSE29q667HTmcpaCBsc38am7V7UgnpA-b2TbmmOeU7HQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 3, 2016 at 11:37 PM, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> wrote:
>> ALTER TABLE my_table
>> DISABLE INDEX ALL;
>
> +1
> This very thing came up in a conversation with PeterG early last year. I was
> in favor then and I was surprised that the only thing standing in the way
> was a lack of ALTER TABLE syntax.
> Creating temporary data structures to mimic existing metadata structures is
> a pain.

As long as the exclusive lock is kept until the end of the transaction
that would make it. I got scared when reading $subject that you were
going to propose a ENABLE ALL. This command should be a no-opt outside
a transaction block though.

>> It'd be even better to also add a REINDEX flag to COPY, where it
>> disables indexes and re-creates them after it finishes. But that could
>> be done separately.
>
> I'm iffy on the COPY change. If we add index rebuilding, why not disabling
> as well? If the COPY fails, what state do we leave the indexes in?

Yeah, I am -1 on that. Leaving the indexes in an unclean state would
force the users to REINDEX anyway afterwards.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-11-04 00:03:41 Re: WAL consistency check facility
Previous Message Karl O. Pinc 2016-11-03 23:34:50 Re: Patch to implement pg_current_logfile() function