| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Vick Khera <vivek(at)khera(dot)org> |
| Cc: | Jason Dusek <jason(dot)dusek(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Large empty table, balanced INSERTs and DELETEs, not being vacuumed |
| Date: | 2016-10-22 07:11:46 |
| Message-ID: | CAB7nPqR3w4qjDTgvu2BMumRxOQHr3BT4WLYHma+7OzsVGGyj+Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sat, Oct 22, 2016 at 6:02 AM, Vick Khera <vivek(at)khera(dot)org> wrote:
> On Fri, Oct 21, 2016 at 4:53 PM, Jason Dusek <jason(dot)dusek(at)gmail(dot)com> wrote:
>> This is really only a temporary fix, though. We can have a cron job running
>> in the background running TRUNCATE ONLY ... but this seems like the kind of
>> thing that auto-vacuuming should have handled for us, before the problem got
>> “too large”. Are there auto-vacuum settings that we can set, globally or on
>> the table, to address this situation?
>
> Did auto-vacuum actually succeed in vacuuming this table? Check your
> logs. You may need to make auto vacuum more log-verbose first.
Yeah. If you are using 9.5 or newer versions, you could set
log_autovacuum_min_duration to 0 for this relation and avoid a lot of
noise in your logs. pg_stat_user_tables and pg_stat_all_tables also
contain information regarding the last time autovacuum has been run on
a relation.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Farber | 2016-10-22 11:12:13 | Re: Selecting records with highest timestamp - for a join |
| Previous Message | Michael Paquier | 2016-10-22 07:04:15 | Re: Replication rolling back to normal. |