On Mon, Aug 03, 2020 at 01:04:45PM -0500, Ron wrote:
> same definition, and when that is complete, drop the old index. The
> locking that is required here is modest: CREATE INDEX CONCURRENTLY
> needs to lock the table briefly at a couple of points in the
> operation, and dropping the old index req
>
> creating another index concurrently is taking lot of time
>
Could you increase maintenance_work_mem significantly or is that already
quite high?
On 8/3/20 12:58 PM, Christophe Pettus wrote
On Aug 3, 2020, at 10:20, Konireddy Rajashekar wrote:
Could you please suggest any ideal approach to tackle this ?
You can do CREATE INDEX CONCURRENTLY to build a new index with the same
definition, and when that is complete, drop the old index. The
> On Aug 3, 2020, at 10:20, Konireddy Rajashekar wrote:
> Could you please suggest any ideal approach to tackle this ?
You can do CREATE INDEX CONCURRENTLY to build a new index with the same
definition, and when that is complete, drop the old index. The locking that is
required here is mode
Hi Team,
i have a table of size 2.6TB which is very prone to updates and inserts so
we have tuned autovacuum to run on it very aggressively , so the table
level bloat is fine .
Now we are facing issue with indexes on this table. the total size of all
indexes on this table is around 2.4TB.
There
