Re: Disabling an index temporarily - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Disabling an index temporarily
Date
Msg-id CADkLM=dyM93Kfigrp=fcCFz8HuTVLzyOLUEPvRLeTasUT2dpZQ@mail.gmail.com
Whole thread Raw
In response to Re: Disabling an index temporarily  (Bill Moran <wmoran@potentialtech.com>)
List pgsql-hackers
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 13, 2015 at 10:23 PM, Bill Moran <span
dir="ltr"><<ahref="mailto:wmoran@potentialtech.com" target="_blank">wmoran@potentialtech.com</a>></span>
wrote:<br/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">OnSun, 13 Dec 2015 22:15:31 -0500<br /> Corey Huinker <<a
href="mailto:corey.huinker@gmail.com">corey.huinker@gmail.com</a>>wrote:<br /><br /> > ALTER TABLE foo DISABLE
[NONUNIQUE]INDEXES<br /> > -- same, but joining to pg_class and possibly filtering on indisunique<br /><br
/></span>Iwould think that NONUNIQUE should be the default, and you should have<br /> to specify something special to
alsodisable unique indexes. Arguably,<br /> unique indexes are actually an implementation detail of unique<br />
constraints.Disabling a performance-based index doesn't cause data<br /> corruption, whereas disabling an index created
aspart of unique<br /> constraint can allow invalid data into the table.<br /><br /> Just my $.02 ...<br /><span
class="HOEnZb"><fontcolor="#888888"><br /> --<br /> Bill Moran<br /></font></span></blockquote></div><br /></div><div
class="gmail_extra">I'dbe fine swapping NONUNIQUE for ALL and defaulting to non-unique, or flatly enforcing a rule that
itwon't disable the index required by an enabled constraint.</div><div class="gmail_extra"><br /></div><div
class="gmail_extra"><br/></div></div> 

pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Disabling an index temporarily
Next
From: Konstantin Knizhnik
Date:
Subject: Re: Logical replication and multimaster