| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Anna Akenteva <a(dot)akenteva(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ... |
| Date: | 2020-09-04 15:37:17 |
| Message-ID: | a4e73bb6f015bb465dec0d7604783a91ea22a44f.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2020-09-04 at 10:41 -0400, Alvaro Herrera wrote:
> > The value I see in this is:
> > - replacing a primary key index
> > - replacing the index behind a constraint targeted by a foreign key
>
> But why is this better than using REINDEX CONCURRENTLY?
It is not better, but it can be used to replace a constraint index
with an index with a different INCLUDE clause, which is something
that cannot easily be done otherwise.
For exclusion constraints it is pretty useless, and for unique
constraints it can be worked around with CREATE UNIQUE INDEX CONCURRENTLY.
Admitted, the use case is pretty narrow, and I am not sure if it is
worth adding code and SQL syntax for that.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2020-09-04 15:50:55 | Re: Add session statistics to pg_stat_database |
| Previous Message | Kelly Min | 2020-09-04 15:31:55 | [PATCH] Comments related to " buffer descriptors“ cache line size" |