Re: [GENERAL] Speeding up an in-progress wraparound-preventing vacuum

2014-12-10 Thread Jeff Janes
On Mon, Dec 8, 2014 at 4:58 PM, Vincent de Phily vincent.deph...@mobile-devices.fr wrote: On Monday 08 December 2014 10:17:37 Jeff Janes wrote: On Mon, Dec 8, 2014 at 4:54 AM, Vincent de Phily I don't think that routine vacuums even attempts to update relfrozenxid, or at least doesn't

Re: [GENERAL] Speeding up an in-progress wraparound-preventing vacuum

2014-12-09 Thread Vincent de Phily
On Tuesday 09 December 2014 01:58:11 Vincent de Phily wrote: On Monday 08 December 2014 10:17:37 Jeff Janes wrote: You can `strace` for the lseek command to see which file handles it is currently working on, and use lsof to turn those into names. You want to look at where it is in the

Re: [GENERAL] Speeding up an in-progress wraparound-preventing vacuum

2014-12-09 Thread Tom Lane
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

Re: [GENERAL] Speeding up an in-progress wraparound-preventing vacuum

2014-12-09 Thread Vincent de Phily
On Tuesday 09 December 2014 16:56:39 Tom Lane wrote: 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),

Re: [GENERAL] Speeding up an in-progress wraparound-preventing vacuum

2014-12-09 Thread Tom Lane
Vincent de Phily vincent.deph...@mobile-devices.fr writes: What happens when vacuum is killed before it had time to go though the index with its dead-TID buffer ? The next run will go through the index again, looking for those same TIDs (and possibly more). regards,

[GENERAL] Speeding up an in-progress wraparound-preventing vacuum

2014-12-08 Thread Vincent de Phily
Hi List, I have a autovacuum: VACUUM ANALYZE public.some_big_table (to prevent wraparound) that has been running for over 13 days. The process is consuming IO so I'm confident it isn't stuck, but it's still taking surprisingly long. PG 9.1.13 on Debian. The actual table is 584G on a SAN, plus

Re: [GENERAL] Speeding up an in-progress wraparound-preventing vacuum

2014-12-08 Thread Jeff Janes
On Mon, Dec 8, 2014 at 4:54 AM, Vincent de Phily vincent.deph...@mobile-devices.fr wrote: Hi List, I have a autovacuum: VACUUM ANALYZE public.some_big_table (to prevent wraparound) that has been running for over 13 days. The process is consuming IO so I'm confident it isn't stuck, but it's

Re: [GENERAL] Speeding up an in-progress wraparound-preventing vacuum

2014-12-08 Thread Vincent de Phily
On Monday 08 December 2014 10:17:37 Jeff Janes wrote: On Mon, Dec 8, 2014 at 4:54 AM, Vincent de Phily bloat, which I'd like to get back asap). Currently about 80% of the IO is devoted to the vacuum process (on average throughout the day, as extrapolated from atop output). Is that