<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 13, 2015 at 11:03 PM, Tom Lane <span
dir="ltr"><<ahref="mailto:tgl@sss.pgh.pa.us" target="_blank">tgl@sss.pgh.pa.us</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">JeffJanes <<a href="mailto:jeff.janes@gmail.com">jeff.janes@gmail.com</a>> writes:<br /> > Not to
hijackthe thread even further in the wrong direction, but I<br /> > think what Corey really wants here is to stop
maintainingthe index at<br /> > retail while preserving the existing definition and existing index<br /> > data,
andthen to do a wholesale fix-up, like what is done in the 2nd<br /> > half of a create index concurrently, upon
re-enablingit.<br /><br /></span>Meh. Why not just drop the index? I mean, yeah, you might save a few<br />
keystrokeswhen and if you ever re-enable it, but this sure seems like<br /> a feature in search of a use-case.<br /><br
/> regards, tom lane<br /></blockquote></div><br /></div><div class="gmail_extra">Sorry, I
misreadTatsu's initial post. I thought the disabling was for the purpose of reducing overhead on large DML operations,
notplan experimentation.</div><div class="gmail_extra"><br /></div><div class="gmail_extra">Jeff's suggestion is one
use-case.The work of discovering what indexes exist on a table (because it may have changed since you last wrote that
code),saving those names and definitions to an intermediate table, disabling them, doing the big DML operation, and
thenre-enabling them is tedious and error prone, both in the coding of it and the error handling. Leaving the index
definitionsin the data dictionary is one way to avoid all that.</div><div class="gmail_extra"><br /></div><div
class="gmail_extra"><br/></div></div>