1. We don't need no_aggregate any more, max_aggregate is just as good.

The current no_aggregate statistics are: file allocation size, file magic number, file major/minor version, and file column-store fixed-record length, and the maximum value is at least as good as the last one we find (and in some cases, such as the file allocation size, arguably better).

The reason I'm thinking about this is that reading from slot 0 is a little dangerous, it assumes there's a WT_STAT_XXX_SET call in the code that updates this specific statistic. There's nothing that enforces that convention, they could get out of sync. (And, given it's not totally insane to have both WT_STAT_XXX_SET and INCR/DECR calls mixed together, it's hard to imagine a convention that would work.)

The change would be to remove no_aggregate and replace it with max_aggregate.

2. Most of the WT_CONNECTION statistics are not marked max_aggregate, so we generate bad code for them, for example:

to->txn_checkpoint_generation += WT_STAT_READ(from, txn_checkpoint_generation);

It's safe because we never do anything other than WT_STAT_XXX_SET calls for those particular statistics, which clears every slot and then sets the 0 slot, but it still bugs me.

I can imagine a future variant of WT_STAT_XXX_SET that set a value into whatever slot the session is using, and we'd pick the largest (or smallest) value from the set of values during aggregation, and then this code would break.

As I said, this isn't a problem at the moment, but it's not right, either.

The change would be to add max_aggregate to the WT_CONNECTION statistics where we're not aggregating values, and then add a WT_STAT_READ_MAX call that returns the max value from a set of statistics.