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? ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
