Everything one call to ergon:start_consumer/2 creates.

ergon_pgmq_sup (rest_for_one)
  |- pgo pool       only when long polling; a single dedicated connection
  |- wpool          concurrency x ergon_pgmq_runner
  \- consumer       the batch cycle

rest_for_one in dependency order, as in ergon_queue_sup: the consumer casts into the pool, so the pool must exist first and the consumer must come back with it. A consumer crash leaves the runners to finish what they hold.

The long-poll connection

A long-polling read blocks server-side for up to max_poll_seconds, holding its connection for the whole call. Issued against the shared pool that would take a connection out of circulation for every other query on the node, and with a few such consumers it would empty the pool entirely.

So a long-polling consumer gets a pgo pool of its own, sized one, and its reads are pinned to it through the query_options() that ergon_sql:query/3 threads down to the driver. Consumers that do not long poll share the main pool as everything else does: their reads return immediately.

pgo pools live under pgo_sup rather than here, for the same reason ergon_repo's does, so this supervisor starts it in init/1 and does not list it as a child.