from Hacker News

Odyssey – Scalable PostgreSQL connection pooler

by pmwkaa on 5/30/18, 1:25 PM with 40 comments

  • by doh on 5/30/18, 2:56 PM

    This looks pretty interesting. Will definitely spend some time testing it.

    Shameless plug. We have recently forked pgbouncer to add multicore support[0]. We are running in production for couple of weeks and the performance is great.

    Our design is very straightforward. Instead of touching the current code, we've extended it by a manager, that spins workers, which are essentially forks of pgbouncer itself (one per core, or whatever you specify in the settings), and then distributes the connections between the clients and the workers. So if you decide not to use the multiprocessing part, you can just turn it off and you will be running the same old pgbouncer you are used to. It also allows for the code to be merged to the original code base without any significant changes.

    [0] https://github.com/pexeso/pgbouncer-smp

  • by nh2 on 5/30/18, 3:43 PM

    Out of curiosity, is there a point in using a connection pooler if your application does not follow the PHP approach to things?

    That is, if you don't create a new DB connection for each HTTP request, but instead create one (or a few) connections at webserver startup time, which can serve all coming requests?

  • by kodablah on 5/30/18, 2:22 PM

    I often wonder why connections aren't made more lightweight in Postgres, or if there was an option to steal a connection and have a "RESET" command that destroyed all state. In my Postgres library, I have to keep state information too just so I can "reset" a connection. Also maybe the protocol can add a (optionally client supported) PING to check for socket death to know if a connection is stealable.
  • by grillorafael on 5/30/18, 2:06 PM

    Would be interesting to have a side by side comparison with PgBouncer
  • by LoSboccacc on 5/30/18, 2:00 PM

    > Advanced transactional pooling > Odyssey tracks current transaction state and in case of unexpected client disconnection can emit automatic Cancel connection and do Rollback

    that's my biggest issue with pgbouncer, is there a docker image for it?

  • by arvidkahl on 5/30/18, 4:11 PM

    I have been looking into this (and pgpool2 and pgbouncer) and what I found most suprising was both the lack of workable Docker images and any hint of a SaaS solution for this problem.

    Connection Pooling as a Service, why does this not exist? What factors could cause this to be a bad idea? Need for proximity? Network speeds? Security?

  • by igammarays on 5/31/18, 2:45 AM

    Noob question: are we supposed to run a connection pooler on each backend webserver instance, or have every server connect to this (i.e. this is another microservice)?

    And no usage examples?