Re: Speeding up an in-progress wraparound-preventing vacuum

Vincent de Phily <vincent(dot)dephily(at)mobile-devices(dot)fr> writes:
> It reads about 8G of the table (often doing a similar number of writes, but
> not always), then starts reading the pkey index and the second index (only 2
> indexes on this table), reading both of them fully (some writes as well, but
> not as many as for the table), which takes around 8h.

> And the cycle apparently repeats: process a few more GB of the table, then go
> reprocess both indexes fully. A rough estimate is that it spends ~6x more time
> (re)processing the indexes as it does processing the table (looking at data
> size alone the ratio would be 41x, but the indexes go faster). I'm probably
> lucky to only have two indexes on this table.

> Is that the expected behaviour ?

Yes. It can only remember so many dead tuples at a time, and it has
to go clean the indexes when the dead-TIDs buffer fills up. You could
increase maintenance_work_mem to increase the size of that buffer.

regards, tom lane