Re: how to investigate GIN fast updates and cleanup cycles? - Mailing list pgsql-general

From Steve Kehlet
Subject Re: how to investigate GIN fast updates and cleanup cycles?
Date
Msg-id CA+bfosFrsKVLHj+iwWiP3puT7+KNY9vrZQT7h-WRRn2-nQMcyg@mail.gmail.com
Whole thread Raw
In response to Re: how to investigate GIN fast updates and cleanup cycles?  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: how to investigate GIN fast updates and cleanup cycles?
List pgsql-general
On Fri, Aug 28, 2015 at 12:10 PM Jeff Janes <jeff.janes@gmail.com> wrote:
Did you change the system-wide autovacuum_analyze_scale_factor?  If so, don't do that.  You can use a table's storage parameters to set a custom autovacuum_analyze_scale_factor just for individual tables.  So just the table with the troublesome gin index:
 
No I did it just to the problematic table:

ALTER TABLE my_table SET (autovacuum_vacuum_scale_factor=0);
ALTER TABLE my_table SET (autovacuum_analyze_scale_factor=0);

My system-wide autovacuum_analyze_threshold is 50 so I think that's ok.

There is a bulk load going on right now so a lot of tables are needing vacuuming. I really need to increase my autovacuum_max_workers.
 
 
Killing existing vacuums won't help (at least not until change your system wide setting back and so the above instead) because it will likely just restart on the same table it was on when you killed it.

You're right, I gave up trying, and am back running a manual VACUUM. It's slow, but I can't bounce the db right now.

pgsql-general by date:

Previous
From: Jeff Janes
Date:
Subject: Re: how to investigate GIN fast updates and cleanup cycles?
Next
From: Steve Kehlet
Date:
Subject: Re: how to investigate GIN fast updates and cleanup cycles?