On Mon, May 6, 2019 at 12:18 PM Andres Freund <andres@anarazel.de> wrote:
> > None of that addresses the question of the distributed cost of sending
> > more sinval messages. If you have a million little tiny relations and
> > VACUUM goes through and clears one tuple out of each one, it will be
> > spewing sinval messages really, really fast. How can that fail to
> > threaten extra sinval resets?
>
> Vacuum triggers sinval messages already (via the pg_class update),
> shouldn't be too hard to ensure that there's no duplicate ones in this
> case.
Yeah, if we can piggyback on the existing messages, then we can be
confident that we're not increasing the chances of sinval resets.
> > Well, that seems like an argument that we just shouldn't do this at
> > all. If the FSM is worthless for small relations, then eliding it
> > makes sense. But if having it is valuable even when the relation is
> > tiny, then eliding it is the wrong thing to do, isn't it?
>
> Why? The problem with the entirely stateless proposal is just that we'd
> do that every single time we need new space. If we amortize that cost
> across multiple insertions, I don't think there's a problem?
Hmm, I see.
> Note that without additional state we do not *know* that the heap is 5
> pages long, we have to do an smgrnblocks() - which is fairly
> expensive. That's precisely why I want to keep state about a
> non-existant FSM in the relcache, and why'd need sinval messages to
> clear that. So we don't incur unnecessary syscalls when there's free
> space.
Makes sense.
> > I guess you could incur the overhead repeatedly if the relation starts
> > out at 1 block, grows to 4, is vacuumed back down to 1, lather, rinse,
> > repeat, but is that actually realistic? It requires all the live
> > tuples to live in block 0 at the beginning of each vacuum cycle, which
> > seems like a fringe outcome.
>
> I think it's much more likely to be encountered when there's a lot of
> churn on a small table, but HOT pruning removes just about all the
> superflous space on a regular basis. Then the relation might actually
> never get > 4 blocks.
Yeah, but if it leaves behind any tuples in block #3, the relation
will never be truncated. You can't repeatedly hit the
all-blocks-are-full case without repeatedly extending the relation,
and you can't repeatedly extend the relation without getting beyond 4
blocks unless you are also truncating it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company