Percona Server moved to https://jira.percona.com/projects/PS

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

Asked by Mike Siekkinen

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

Language:
English Edit question
Status:
Answered
For:
Percona Server moved to https://jira.percona.com/projects/PS Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
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.