Vincent de Phily <vincent.dephily@xxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
