This plugin is no longer needed. The custom table code is now part of Action Scheduler version 3.0 and newer. If you're using the latest Action Scheduler, you have the most performant schema available.
The last remaining bottleneck I've seen on live sites when using AS with custom tables are queries for actions for a specific set of args. As args are often used to link an action to another object, like a subscription or membership, this is a common use case.
While this "bottleneck" is minor, a few seconds even on large sites, it can add up.
For example, when a subscription renewal is processed, the subscriptions status is first changed to on-hold, after which all scheduled actions for that subscription are unscheduled, which includes both a query to unschedule the next scheduled, and check if there are any others scheduled that need to be unscheduled (code: https://cl.ly/18450k122y0l )... then if the renewal payment is processed successfully, in the same request, all the subscriptions scheduled actions, like expiration, next payment etc. will be scheduled again... but only if there isn't already one scheduled, which requires another query on scheduled actions for that subscription, for each action to be scheduled. This means even a few seconds can add up to 10-20 seconds quite easily. While this specific example could be addressed by refactoring in Subscriptions, that refactoring is unnecessary when args is indexed, because the query time drops to 0.15 seconds.
Indexes on fulltext column types aren't ideal. And really, the args column doesn't need to be a fulltext. It's only set to that type for backward compatibility with the post_content column which was previously used to store args.
Changing the column to a varchar(255) type won't break the plugins I've seen using AS. However, we should check other use cases through GitHub code search, and also by adding a notice to AS core to prepare for this change (see https://github.com/Prospress/action-scheduler/issues/185 for that).
The last remaining bottleneck I've seen on live sites when using AS with custom tables are queries for actions for a specific set of args. As args are often used to link an action to another object, like a subscription or membership, this is a common use case.
While this "bottleneck" is minor, a few seconds even on large sites, it can add up.
For example, when a subscription renewal is processed, the subscriptions status is first changed to on-hold, after which all scheduled actions for that subscription are unscheduled, which includes both a query to unschedule the next scheduled, and check if there are any others scheduled that need to be unscheduled (code: https://cl.ly/18450k122y0l )... then if the renewal payment is processed successfully, in the same request, all the subscriptions scheduled actions, like expiration, next payment etc. will be scheduled again... but only if there isn't already one scheduled, which requires another query on scheduled actions for that subscription, for each action to be scheduled. This means even a few seconds can add up to 10-20 seconds quite easily. While this specific example could be addressed by refactoring in Subscriptions, that refactoring is unnecessary when
argsis indexed, because the query time drops to 0.15 seconds.Indexes on
fulltextcolumn types aren't ideal. And really, theargscolumn doesn't need to be afulltext. It's only set to that type for backward compatibility with thepost_contentcolumn which was previously used to store args.Changing the column to a
varchar(255)type won't break the plugins I've seen using AS. However, we should check other use cases through GitHub code search, and also by adding a notice to AS core to prepare for this change (see https://github.com/Prospress/action-scheduler/issues/185 for that).