* Tom Lane (t...@sss.pgh.pa.us) wrote: > This seems like a pretty clear bug to me; does anyone want to argue > that it isn't?
I'd agree that it's a bug. > In the case of pg_stat_get_xact_tuples_inserted and a couple of other > routines, it would be entirely trivial to fix: just ignore > tabentry->t_counts.t_tuples_inserted (which is the count held over from > previous transactions) and only total the trans->tuples_inserted counters. > However, for a number of other counters such as blocks_fetched, we don't > store transaction-local counts separately, and would have to start doing > so if we wanted to make these functions work as documented. I've been thinking for a while that we need more of this (storing and aggregating statistics data locally first) or we're never going to be able to add more information like the stddev, etc, that's been requested. I'd really like to see us collecting a great deal more regarding stats and that's not going to happen unless we can cache and aggregate locally first. > Thoughts? I have other things to do right now than fix this myself. While a bug, I don't feel that it's a particularly high priority one. What worries me more is the risk of breaking things if we do backpatch a fix that postpones updating some information that used to be reflected immediately. It seems like we'd need/want some kind of generalized structure for this too, which would be even more work and which has zero chance for 9.4, meaning that it'll need to be fixed one way now and then whacked around in 9.5 (assuming someone has the time, etc..). Not a good situation. :/ Thanks, Stephen
signature.asc
Description: Digital signature