A customer reported that a snapshot of the statistics is taken when the cursor is opened, and those values are not re-initialized as part of the WT_CURSOR.reset call.

I'm not sure if that's right or not, to be honest. The current documentation says only that WT_CURSOR.reset "resets the position" of the cursor, but as I said, I can see how someone might reasonably expect WT_CURSOR.reset to re-initialize the values.

michaelcahill comments:

> I can see the argument for having reset on a statistics cursor refresh the values, but what I would actually suggest we do is to lazily refresh a statistics cursor on the first read after a reset (or open).

> That way, an application can do whatever queries it wants, then reset the cursor and stash it somewhere for as long as it likes. That matches best practice for table and index cursors, which should be reset when queries complete. The next time the application does a read (WT_CURSOR->next or WT_CURSOR->search), the data is refreshed.

> All of the current uses of statistics cursors I am aware of either do a full scan, then close the cursor, or do a sequence of searches. I don't think that changing the semantics of reset for statistics cursors will cause anyone any trouble, but that needs some investigation before I want to commit to making the change.