Re: VACUUM's ancillary tasks

On Sat, Oct 1, 2016 at 1:34 PM, Vik Fearing <vik(at)2ndquadrant(dot)fr> wrote:

>
> Sure, I could handle each case separately, but the goal of this patch
> (as hinted at in the Subject) is to generalize all the different tasks
> we've been giving to VACUUM. The only missing piece is what the first
> patch addresses; which is insert-mostly tables never getting vacuumed.
>

I don't buy the argument that we should do this in order to be "general".
Those other pieces are present to achieve a specific job, not out of
generality.

If we want to have something to vacuum insert-mostly tables for the sake of
the index-only-scans, then I don't think we can ignore the fact that the
visibility map is page based, not tuple based. If we insert 10,000 tuples
into a full table and they all go into 100 pages at the end, that is very
different than inserting 10,000 tuples which each go into a separate page
(because each page has that amount of freespace). In one case you have
10,000 tuples not marked as all visible, in the other case you have
1,000,000 not marked as all visible.

Also, I think that doing more counts which get amalgamated into the same
threshold, rather than introducing another parameter, is a bad thing. I
have insert-mostly, most of the time, tables which are never going to
benefit from index-only-scans, and I don't want to pay the cost of them
getting vacuumed just because of some inserts, when I will never get a
benefit out of it. I could turn autovacuum off for those tables, but then
I would have to remember to manually intervene on the rare occasion they do
get updates or deletes. I want to be able to manually pick which tables I
sign up for this feature (and then forget it), not manually pick which ones
to exempt from it and have to constantly review that.

Cheers,

Jeff