Re: Disabling indexes on a table
От | Laurenz Albe |
---|---|
Тема | Re: Disabling indexes on a table |
Дата | |
Msg-id | 66028fd5cc301f5726d759e46903f88f8c18217f.camel@cybertec.at обсуждение исходный текст |
Ответ на | Disabling indexes on a table (John Scalia <jayknowsunix@gmail.com>) |
Ответы |
Re: Disabling indexes on a table
|
Список | pgsql-admin |
On Thu, 2021-02-18 at 11:24 -0500, John Scalia wrote: > One of my developers asked me about this, and he suggested running the following update: > > UPDATE pg_index SET indisready=false > WHERE indrelid = (select oid from pg_class where release = ‘his_table’); > > I told him it’s never a good idea to update anything in a system catalog by hand, > but that I would reach out here for a better opinion. Am I correct that he > shouldn’t try this, or is he OK to do this? His table has approximately 8 > different indexes on it, and those really slow down his bulk loads. > Usually when I have to get involved, I just drop his indexes and rebuild > them afterwards, and I know that is always safe. https://www.postgresql.org/docs/current/catalog-pg-index.html says: indisready bool If true, the index is currently ready for inserts. False means the index must be ignored by INSERT/UPDATE operations. So that would indeed speed up a bulk load, but your indexes would be unusable afterwards. If you run a second update to "pg_index" to set "indisready" to TRUE, you would end up with corrupted indexes. The indexes will be useless and can only be dropped. So you are right that that is not a good idea. Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
В списке pgsql-admin по дате отправления: