Originally posted by @dimitri in https://github.com/dimitri/pgloader/timeline

That's good thinking, and I think that's relevant for another PR. The PR introducing the statistics singleton should also take care of the following bits of refactoring of the code:

• the singleton is named “state” as I initially though I would update the global state of the migration to be able to know about the progress being made while it's being made,
• when implementing the feature, it quickly enough turned into statistics (count of rows read, imported, errors, timings, etc) rather “state”
• the API to access and maintain the state objects (stats really) per table etc is rather lacking, so we should clean that up and offer easy access to needed information from threads

At the moment only the monitor thread is creating and updating the data, we certainly want to keep it that way. That allows no-locks (and no dead locks) code, with using a queue to send events and centralise statistics from.