Last modified: 2014-06-23 16:07:12 UTC
On enwiki: +---------------+------------+-----------+ | table_name | index_name | rows_read | +---------------+------------+-----------+ | blob_tracking | bt_moved | NULL | | blob_tracking | bt_cluster | NULL | +---------------+------------+-----------+ NULL rows_read indicates the indexes havn't been used for reading or writing. Stats collection has been running here for over a week. Same results on S1 master and several slaves, and various other wikis. Data / index disk usage for blob_tracking is roughly 50/50 split. Dropping unused indexes would be good to reduce write load and save disk space. But are these indexes really likely to be simply unused? Is there any infrequent maintenance or reporting job that requires them?
(In reply to comment #0) > But are these indexes really likely to be simply unused? Is there any > infrequent maintenance or reporting job that requires them? maintenance/storage/trackBlobs.php creates and populates this table. maintenance/storage/recompressTracked.php uses the data stored in it. Given that the former script, when run, will delete and recreate the table, can the entire table just be deleted (and recreated when the next recompression run happens)?
(In reply to comment #1) > Given that the former script, when run, will delete and recreate the table, > can the entire table just be deleted (and recreated when the next > recompression run happens)? Yes. I wanted to keep it around for a while, to allow reconstruction of the old text table in case a data loss bug in recompressTracked.php was discovered, but the source clusters have been deleted now (11, 12, 16, 17, 18, 19), so that justification no longer holds. Also, it's been 3 years since it was last run, with no such bugs being reported.
