Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ...
В списке pgsql-hackers по дате отправления:
| От | Laurenz Albe |
|---|---|
| Тема | Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ... |
| Дата | |
| Msg-id | a4e73bb6f015bb465dec0d7604783a91ea22a44f.camel@cybertec.at обсуждение исходный текст |
| Ответ на | Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ... (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Ответы |
Re: Change a constraint's index - ALTER TABLE ... ALTER CONSTRAINT ... USING INDEX ...
|
| Список | 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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера