Clarify incompatibility between batch_size and map_joinable

We're undertaking a series of large data imports that are currently implemented using migrate.

The source table is located on the same database server as the core Drupal database - indeed it's in the same database. The table currently contains a total of 500,000 records (but will end up larger than that).

We're currently undertaking an initial import, so are running as:

drush mi Migration --limit="9 minutes"

as a periodic scheduled job.

Initial partial imports were perfectly performant. However - as the number of imported items has increased our migrate jobs (Being run through drush) are getting less, and less effective. We've identified that the bottleneck is migrate working out which rows it needs to import. Query logging led us to the following query being repeated over and over again with incrementing OFFSETs:

SELECT l.*
FROM 
import_table l
WHERE  (provider = 'xxxx') 
LIMIT 1000 OFFSET 90000

Given the size of our data set it's imperitive that we set a batch_size on the process - loading 500,000 records into memory isn't going to work :)

However - it seems that doing so is causing migrate to have to read all rows in chunks of 1,000 in order to establish if they need migrating instead of joining onto the map table and making the MySQL server do the work. Looking into sql.inc I found the following code:

if (isset($options['batch_size'])) {
      $this->batchSize = $options['batch_size'];
      // Joining to the map table is incompatible with batching, disable it.
      $options['map_joinable'] = FALSE;
    }

I'm not sure why having a batch_size would be incompatible with joining onto the map table especially as it seems that the two things are likely to go hand in hand with large data sets?

Is this something that can be resolved easily? We'd be happy to help investigate / test or contribute if someone thinks this is achievable. Equally if someone has investigated, and discounted this already that'd be great to know and we'll probably need to roll a custom solution.