Avoid 5.57 upgrade taking hours on large activity tables #25380
Conversation
|
(Standard links)
|
demeritcowboy
force-pushed
the
act-rev
branch
from
2fa1679
to
125318f
Compare
| public function setPreUpgradeMessage(&$preUpgradeMessage, $rev, $currentVer = NULL) { | ||
| if ($rev === '5.57.alpha1') { | ||
| if (CRM_Core_DAO::singleValueQuery('SELECT COUNT(id) FROM civicrm_activity WHERE is_current_revision = 0')) { | ||
| // The query on is_current_revision is slow if there's a lot of activities. So limit when it gets run. | ||
| $activityCount = CRM_Core_DAO::singleValueQuery('SELECT COUNT(id) FROM civicrm_activity'); |
There was a problem hiding this comment.
This is an improvement but actually SELECT COUNT is a slow query on large DBS. Despite the limitations SELECT MAX(id) is better
There was a problem hiding this comment.
actually - sorry this is not the query I thought it was - I was thinking of those slow COUNT queries @totten added which decide whether to create snapshots
There was a problem hiding this comment.
Nope I was right the first time - this query WOULD be better with the SELECT MAX(id) to speed it up
|
@demeritcowboy this looks good to me - I made some comments about the slowness of |
eileenmcnaughton
added
the
merge ready
demeritcowboy
force-pushed
the
act-rev
branch
from
125318f
to
4199e21
Compare
|
Thanks. That's smart. |
|
test this please |
|
@johntwyman @andrew-cormick-dockery this is RTYI |
|
Upgrade went will with this patch included |
|
Yes, I included this patch when upgrading to 5.57.1, and it went a lot better than without it. |
|
This should fix a less significant slow query issue - #25420 |
Overview
As discussed in chat, the queries on is_current_revision and original_id perform badly on large activity tables. This only runs them if you don't have a lot of activities. If it can't run the queries then it points you to the lab snippet which also contains the queries you can run manually.
Before
Slow
After
Technical Details
Comments