From: | Steve Kehlet <steve(dot)kehlet(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Forums postgresql <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: how to investigate GIN fast updates and cleanup cycles? |
Date: | 2015-08-28 19:25:08 |
Message-ID: | CA+bfosFrsKVLHj+iwWiP3puT7+KNY9vrZQT7h-WRRn2-nQMcyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Aug 28, 2015 at 12:10 PM Jeff Janes <jeff(dot)janes(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Kehlet | 2015-08-28 19:36:38 | Re: how to investigate GIN fast updates and cleanup cycles? |
Previous Message | Jeff Janes | 2015-08-28 19:10:25 | Re: how to investigate GIN fast updates and cleanup cycles? |