Re: Skip index cleanup if autovacuum did not do any work

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Feike Steenbergen <feikesteenbergen(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Skip index cleanup if autovacuum did not do any work
Date: 2017-11-28 22:00:39
Message-ID: CAH2-Wz=Vy-vgBSARbj5H9XSaNcn+Hz2nP=o=j2S55w2P92qaHg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 28, 2017 at 1:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> It might be okay to put such a short-circuit in at a lower level,
> eg within the btree AM. I don't remember at the moment whether
> a btree vacuum scan accomplishes anything much if there are no dead
> tuples.
>
> One thing that I think it does do is update the index's pg_class stats
> (relpages/reltuples). Maybe it's okay to skip that in this particular
> scenario, trusting that auto-analyze would fix it, but that seems
> worthy of debate.

One of the sticking points with Sawada-san's patch, that I tried to
work through with him, is that we store XIDs in deleted B-Tree pages,
for the RecentGlobalXmin recycling interlock thing. The assumption is
that anti-wraparound VACUUM doesn't have to worry about those Xids as
a special case, because VACUUM will get around to actually reclaiming
them for the FSM the next time around (maybe that's the VACUUM that
enables advancing the epoch).

We cannot break that assumption, and no easy fixes suggest themselves.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-11-28 22:08:44 Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
Previous Message Tom Lane 2017-11-28 21:55:03 Re: Skip index cleanup if autovacuum did not do any work