Add pgBouncer into Docker image

[rustprooflabs]

Details

Using osm2pgsql for PgOSM Flex creates a relatively large number of connections to Postgres based on the number of tables created by the Flex output. This was discovered here (#226 (comment)) and answered on the osm2pgsql discussion here. Now documented on osm2pgsql.org: https://osm2pgsql.org/doc/manual.html#number-of-connections

It is unlikely this behavior will change in osm2pgsql so the plan is to bake pgBouncer into the Docker image, example standalone pgbouncer image here. Until this is in place, running --append mode will require upping the max_connections to at least 210, preferably 300 to give headroom.

[rustprooflabs]

It's unlikely at this point that PgBouncer will be directly added into this project's Docker image. First challenge is that as of now, pgbouncer does not actually provide any benefit. See osm2pgsql-dev/osm2pgsql#1650 (reply in thread).

Further, putting pgbouncer into the docker image means it needs to be maintained then forever, and I don't see the great benefit to adding that overhead to this project at this time.

[rustprooflabs]

If osm2pgsql changes their connection handling behavior to not hold onto idle connections this can be reconsidered. Though, if they do that, the biggest portion of the problem this was trying to solve would be removed too... either way: closed

[rustprooflabs]

It looks like using pgbouncer in transaction mode might be an option again. Updated discussion on osm2pgsql. The PR was merged in pgbouncer recently, released in not in tagged version yet v1.21.0 "The one with prepared statements".

[rustprooflabs]

Once again, closing... Recent work in osm2pgsql to reduce idle connections has removed my reasoning to work further on this. See #376 for details. The initial import w/ default layerset dropped from 43 connections down to 10. Replication updates dropped from 207 connections down to 17.