Description of problem:
When proceeding with the pulp2 - pulp3 migration, the process will execute some PG queries and according to the # of entries in the customer, this query can spend a long time.

Foe example, here, we can see a single query spent ~12h

---
pulpcore=# SELECT COUNT(*) AS "__count" FROM "pulp_2to3_migration_pulp2rpm" INNER JOIN "pulp_2to3_migration_pulp2content" ON ( "pulp_2to3_migration_pulp2rpm"."pulp2content_id" = "pulp_2to3_migration_pulp2content"."pulp_id" ) where not (not ("pulp_2to3_migration_pulp2content"."pulp3_content_id" IS NULL) and not ( "pulp_2to3_migration_pulp2content"."pulp2_id" IN (SELECT DISTINCT U0."pulp2_unit_id" FROM "pulp_2to3_migration_pulp2lazycatalog" U0 WHERE U0."is_migrated" = false )));

 __count
---------
   93490
(1 row)

Time: 42712560.277 ms (11:51:52.560)
pulpcore=# 
---

Version-Release number of selected component (if applicable):
6.10

How reproducible:
100%

Steps to Reproduce:
1. Enable and sync a lot of repositories, all of them as immediate
2. Proceed with the migration
3.

Actual results:
The process will spend a long time, checking the pulp API, we can see the same step of the pulp talk will be there for hours and the PG will be running the query for hours/days.

Expected results:
The content migration be faster and the PG be not stuck with any kind of query.

Additional info: