Why were the information_schema.*_RESET tables implemented like that?

Asked by Mike Siekkinen on 2012-08-21

There are a couple tables in information_scheam, INNODB_CMP_RESET and INNODB_CMPMEM_RESET. I realize *what* these do: return the current values of INNODB_CMP or INNODB_CMPMEM respectively and resets the values. I realize *why* you would want to reset the counters: they might have overflowed and are useless or you want an easy starting line for tracking growth.

My question is why is flushing these statistics implemented like this?

This is introducing a precedent where select is not longer a read-only operation. We all ready have flush user|client|table_statistics for those counter tables. It seems like it would make much more sense to keep in line with that have have a "flush innodb_cmp" or "flush innodb_cmpmem"

Question information

English Edit question
Percona Server moved to https://jira.percona.com/projects/PS Edit question
No assignee Edit question
Last query:
Last reply:

This question was reopened

Alexey Kopytov (akopytov) said : #1

Those tables were implemented by InnoDB developers, so this question should be addressed to them.

However, I think it was implemented like this to provide an "atomic read + reset" semantics. Suppose there are some change in statistics between "SELECT * FROM INNODB_CMP" and "FLUSH INNODB_CMP". In such a case, those changes would be lost, as in not reflected in the next "SELECT * FROM INNODB_CMP".

Can you help with this problem?

Provide an answer of your own, or ask Mike Siekkinen for more information if necessary.

To post a message you must log in.