Re: pg_stat_get_last_vacuum_time(): why non-FULL?

On Monday, April 8, 2013, Kevin Grittner wrote:

> Jeff Janes <jeff(dot)janes(at)gmail(dot)com <javascript:;>> wrote:
> > Amit Kapila <amit(dot)kapila(at)huawei(dot)com <javascript:;>> wrote:
>
> >> One of the important difference is that during the time VACUUM
> >> FULL is operating on a relation, no other operations will be
> >> allowed on that relation. Most of admin care about this point,
> >> because they don't want to stop operations for background
> >> garbage collect.
>
> > While that is true, it is not a reason not to update
> > pg_stat_get_last_vacuum_time. I'm having a hard time coming up
> > with a reason not to update pg_stat_get_last_vacuum_time with a
> > full vacuum.
> >
> > On version 8.4 and below, you could justify it by saying that
> > VACUUM FULL bloated the indexes and then left them that way, and
> > so we shouldn't update the time field. But that is no longer the
> > case. And even then, doing a ordinary vacuum afterwards isn't
> > going to fix the index bloat, so even that argument is a bit
> > sketchy.
>
> I'm not sure that what we're doing now is correct, but updating
> things as if a normal vacuum had been done would *not* be the thing
> to do. For starters, VACUUM FULL blows away the free space map and
> visibility map for a table.

Ah, OK, that is obvious in retrospect. I was wracking my brain for
stats-collector-aspects and completely forgot about those.

I don't know how hard (for the hackers) or extra work (for the server) it
would be to make VACUUM FULL reset those things to reasonable values. But
it should be fairly easy to at least document them.

One often uses VACUUM FULL when one is up to ones elbows in alligators, so
it is understandable that we would not want to impose another burden on the
server at that particular moment. So I'm leaning towards documenting the
issue. Or are they already, and I'm just missing it?

Cheers,

Jeff