To reduce execution time, you can select specific date periods to run these scripts for. This means that you can target just the recent > months, for which report data is likely to have changed. Note that data for annual reports is stored in the archives for January of the > appropriate year, so it is a good idea to optimize these regularly as well, e.g.
./console database:optimize-archive-tables last2 ./console database:optimize-archive-tables january
We recommend to set up above two commands as a cronjob and have them executed once monthly.
(Last 2 what? Days, weeks, months, years? Which January? Why only 2 examples? etc.)
But after some trial & error, I figured out at least some of the format:
./console database:optimize-archive-tables 2020 ./console database:optimize-archive-tables january-2020 ./console database:optimize-archive-tables october-2022
Still a little confusing, because everything else in Matomo uses the YYYY-MM-DD (or at least YYYY-MM) format, but at least it’s something! Not sure why they did it that way, it might be that the tool is only supposed to be used for months or something, not sure.
Maybe the date format could also be consistent on the whole Matomo API/functions (then another technical issue should be created, I let Matomo team decide...)
This issue has been mentioned on Matomo forums. There might be relevant details there:
@justinvelluppillai how shall we handle such documentation related issues? Shall we directly have a look at those and fix it if possible, or maybe forward them to support/website team, so they can have a look? Putting them into prioritization queue doesn't sound useful though.