When Auto Partition Recovery is enabled for the cluster, any access to a partitioned table (getTable/loadTable etc..) adds the table to a "partition recovery" queue. There is a continuous thread that picks up items (tables) in this queue and runs ALTER TABLE recover partitions on those tables. There is no set schedule: The recovery is queued when the table is accessed via a select/DDL operation on the table. If the table is not accessed, the recovery is not launched. So it is normal to see delays between recoveries on a table.
Recovery happens from the first and for any subsequent access. It also runs when you add a new partition. One method of keeping the catalog of tables with a large number or partitions and files in sync with s3 is to touch the table, perhaps through a view that is referencing the table. This access launches the auto-recovery kicks in.
Note that Auto Partition Recovery does not run when the when a table is first created. Okera highly recommends as a best practice the user run ALTER TABLE RECOVER PARTITIONS immediately following the CREATE TABLE
The Ignoring table log message indicates the table is already in the queue. This message most often appears for tables that are frequently accessed. Auto Partition Recovery is a continuous background process whose function is to keep the partition information updated. Disabling auto recovery would adversely affect queries when new partitioned data is added in s3 since the partition information would become stale.
Automatic Partition Recovery is a catalog maintenance operation that ensures that each partitioned dataset automatically includes new partitions. Unless the datasets contain a very large number of files and are deeply nested, Okera does not recommend disabling this feature.