Hi Gustavo Bordoni (@bordoni),
Nice, that sounds great.
Sure, just let me know when you’ve made any changes, and I’ll update and note the update time accordingly. I’ll keep an eye on CPU usage for multiple sites by monitoring a database CPU utilization histogram to determine if there is a noticeable difference. Each site has a few thousand tribe_event records.
If your update adds an index to the joining columns (wp_tec_occurrences.post_id) and handles dates and times as DATETIME types rather than VARCHAR, it should improve performance because of fewer table scans for joins and less effort (CPU time) in queries that were type casting VARCHAR to DATETIME, especially where the type casting of VARCHAR to DATETIME was occurring in the WHERE clause (which also causes another table scan, since that column as a VARCHAR cannot benefit from an index in the way it’s being used, whereas DATETIME data is stored as 8 bytes, with the first four representing the date, and the last four representing the time, and this format can benefit from a B-Tree index, allowing efficient lookups based on datetime using MySQL’s date and time functions (or LT and GT operators). It’s likely to make a noticeable difference. Looking forward to it.
