EXPLAIN with index_idsite_dates_period shows the key_len as 15; ref is const,const,const,const

If I add ts_archived to the new index, EXPLAIN shows the key_len as 15 still. This suggests adding ts_archived is not beneficial, perhaps because the query contains a WHERE clause with ts_archived >= condition.

Reopening: the name part of the index was removed but it is useful as you might have hundreds of name for a (idsite, date1,date2,period) tuple. Looking at the query in isArchived() in core/ArchiveProcessing.php it looks like the index should be on (idsite,date1,date2,period,name)

Also, the new index structure on the archive_ tables should be upgraded in the update for 0.5.5 so that all Piwik instances are kept consistent. Two main reasons: performance for all users, and if one day we delete the INDEX for a new one, this would not throw errors on installs missing this INDEX.

When I EXPLAIN with both index_idsite_dates_period and index_idsite_dates_period_name, only index_idsite_dates_period is used. With only index_idsite_dates_period_name, EXPLAIN shows ref=null. My decision to exclude name is based on MySQL's apparent preference and the storage consideration. Perhaps the query should be split into two variants -- blob vs numeric.

As for retroactive updates, of course, we can do this. (But I didn't see this done when Piwik went from BLOB to MEDIUMBLOB.)