asset.cache_copy_visibility() can needlessly recalculate the bib visibility vector when transferring deleted asset.call_number rows for located URIs from the source bib to the target bib. If the acn is already logically deleted, it can have no effect on the target bib's visibility.
This can add up. A particular example we encountered was a record that had hundreds of deleted located URIs being merged to a different record. Attempting it resulted in hundreds of recalculations of the bib visibility, which in turn was exacerbated in 3.11+ by the fact that 'ingest.reingest.force_on_same_marc' (when set to avoid reingesting a bib whose MARC hasn't changed) appears to have no effect when queued ingest is turned off, in turn leading to hundreds of re-ingests of the target bib.
ingest.reingest.force_on_same_marc being ignored also means that means there can be an additional 3-4 reingests of the source and target bibs during asset.merge_record_assets() that aren't necessary. As far as I can tell, the main time that target bib needs an ingest during the asset merge is if any located URIs are being moved to it.
Evergreen 3.11+
