| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bill Moran <wmoran(at)potentialtech(dot)com> |
| Cc: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, obartunov(at)gmail(dot)com, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Disabling an index temporarily |
| Date: | 2015-12-14 03:34:53 |
| Message-ID: | 21578.1450064093@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bill Moran <wmoran(at)potentialtech(dot)com> writes:
> I would think that NONUNIQUE should be the default, and you should have
> to specify something special to also disable unique indexes. Arguably,
> unique indexes are actually an implementation detail of unique
> constraints. Disabling a performance-based index doesn't cause data
> corruption, whereas disabling an index created as part of unique
> constraint can allow invalid data into the table.
Maybe I misunderstood, but I thought what was being discussed here is
preventing the planner from selecting an index for use in queries, while
still requiring all table updates to maintain validity of the index.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2015-12-14 03:36:01 | Re: Disabling an index temporarily |
| Previous Message | Jeff Janes | 2015-12-14 03:31:58 | Re: Using quicksort for every external sort run |