On Monday, April 8, 2013, Kevin Grittner wrote:
Jeff Janes <jeff.janes@gmail.com> wrote:
> Amit Kapila <amit.kapila@huawei.com> 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
