| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Don Seiler <don(at)seiler(dot)us> |
| Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Managing autovacuum freezing |
| Date: | 2021-02-11 17:49:18 |
| Message-ID: | CAH2-WznmJKrB=vni_+Cm0KUuyoGQmvCScirhRgVudn2duOnDUA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Thu, Feb 11, 2021 at 9:13 AM Don Seiler <don(at)seiler(dot)us> wrote:
> My understanding is that these manual VACUUM ANALYZE jobs are not freezing rows that regular autovacuuming would otherwise be doing, which leads up to the big anti-wraparound job.
They will freeze rows, but not aggressively. The antiwraparound vacuum
might block on acquiring buffer pins, low level stuff like that.
Perhaps you should change the vacuum_index_cleanup reloption to 'off'
for the table, but make the scripted overnight vacuums directly
specify INDEX_CLEANUP=on. That way index cleanup would still be
performed for the vacuums that run overnight, though not for the
antiwraparound vacuums, where the overhead may be a real issue.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | srinivas oguri | 2021-02-11 18:06:15 | Re: XX000: invalid BTree prefetch end_key |
| Previous Message | Don Seiler | 2021-02-11 17:13:02 | Managing autovacuum freezing |