Vincent de Phily <vincent.deph...@mobile-devices.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


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to