| 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: | Whole Thread | Raw Message | 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? |