Tom Lane wrote:
> I'd argue it's fine: there are tons of people using row-level stats
> via autovacuum, and (AFAICT) just about nobody using 'em for any other
> purpose. Certainly you never see anyone suggesting them as a tool for
> investigating problems on pgsql-performance. Sure, it's a repurposing
> of the stats subsystem, but we should be willing to do that when field
> experience teaches us what's really needed.
>
OK.
> But all that we have is *global* counts. Inferring ratios applicable to
> particular tables seems a big stretch to me. Any given application is
> likely to have some types of transactions that roll back much more often
> than others.
>
Certainly a stretch, but it's far from fatal, the worst case scenario is
we occasionally vacuum a table that might not need it, whereas the way
things stand right now, the worst case is that we never vacuum that
might have a lot of slack space. BTW, I'm only arguing this based on
what is in the stats system now and pondering how we might improve
things if the stats system isn't changed to directly address this problem.
> One thing we could do is tie the stats message sending more tightly to
> top-level transaction commit/abort. (It's already effectively true that
> we send stats only after commit/abort, but we send 'em from the wrong
> place, ie PostgresMain.) Then the semantics of the message could be
> read as "here's what I did before committing" or "here's what I did
> before aborting" and the collector could interpret the counts
> accordingly. However, this still fails in the case where a committed
> top-level transaction includes some failed subtransactions. I think
> the only full solution will involve backends doing some extra work at
> subtransaction commit/abort so that they can report properly classified
> update counts.
Any guess as to the performance implications?