PgBouncer, PgCat, Supavisor Fight!!!

PgBouncer, PgCat, Supavisor Fight!!! | Scaling Postgres 303

Рет қаралды 1,412

Күн бұрын

To get the show notes as well as get notified of new episodes, visit:
www.scalingpostgres.com/episo...
In this episode of Scaling Postgres, we discuss new Postgres releases, performance comparisons between PgBouncer, PgCat and Supavisor, a new extension pg_analytics, and new planner capabilities in PG16.
Want to learn more about Postgres performance?
Join my FREE mini-course called the PostgreSQL Performance Starter Kit here: www.scalingpostgres.com/cours...
Timestamps:
00:00 - Postgres Performance Demystified Webinar
00:42 - PostgreSQL 16.2, 15.6, 14.11, 13.14, and 12.18 Released!
02:15 - Benchmarking PostgreSQL connection poolers: PgBouncer, PgCat and Supavisor
08:46 - pg_analytics: Transforming Postgres into a Fast OLAP Database
11:10 - What’s new in the Postgres 16 query planner / optimizer
12:35 - Faster query plans with Postgres 16: Incremental Sorts, Anti-JOINs and more
12:54 - Recommended resources to improve your knowledge of Databases and PostgreSQL
14:11 - Waiting for PostgreSQL 17 - Support identity columns in partitioned tables
14:43 - Waiting for PostgreSQL 17 - Add new COPY option SAVE_ERROR_TO / Rename COPY option from SAVE_ERROR_TO to ON_ERROR
15:59 - Connecting to Postgres With psql and .pg_service.conf
16:37 - Postgres Not Starting: The Case of the Missing Output
18:05 - Postgres 16 contribution analysis 2023
19:28 - Outro
#postgres #postgresql

Пікірлер: 12

@RU-qv3jl 16 күн бұрын

Appreciate the content and sharing your opinions, thanks.

@rosendo3219 4 ай бұрын

there is also postgresql 15 internals by egor rogov, but has not been translated to english yet

@AmitVarde 4 ай бұрын

pgBouncer can be configured to use multiple CPUs. But it's a little involved and not out of the box. Still it's shocking that this benchmark did not consider that.

@rosendo3219 4 ай бұрын

how can we see all the job openings of AWS team related to postgresql developement? amazon career page is so complicated.

@ianokay 4 ай бұрын

Do you have any videos you can direct to that speak about what the overhead actually is for establishing connections without pooling and how that acts at scale? Is this that video in a sense? Do you have any others? I've always been curious about what that overhead really is and what takes the most overhead in the connection process.

@dishwad 4 ай бұрын

I’m also very curious about this. I currently use Supavisor in front of Postgres. My API server manages a connection pool, but I’ve received advice to just set the connection pool to a size of 1 or don’t use a connection pool at all. I’m worried about this due to the connection overhead involved with connecting to Supavisor for every transaction.

@ScalingPostgres 4 ай бұрын

Well, it depends on what you mean by overhead. The main post in this episode shows how poor latency and throughput can get if connections keep getting re-established for queries. So, it kind of depends on what your application framework is doing and does it have a connection pool. Up to 100 connections it can get pretty bad if you are constantly starting up and breaking down connections.

@ianokay 4 ай бұрын

@@ScalingPostgres I guess that's exactly the crux of the question. What is happening in connection establishment that hurts latency (and throughput) so badly? What occurs there that causes throughout to be so incredibly low? What causes latency, and what are the actual numbers behind the steps in the connection establishment that lead to the results they do at scale when connections need to be made to fulfill requests.

@RU-qv3jl 16 күн бұрын

@@ianokay That is reasonably well documented and can be found with a few google searches. You lose plan reuse and have to create and tear down process all the time. That isn’t free. There are other things as well but I think that if you want help you should at least post what you have done to look into this already. No-one knows your level of knowledge if you don’t share it.

@rosendo3219 4 ай бұрын

why they did not compare pgpool ?

@ScalingPostgres 4 ай бұрын

Not sure? PgCat and Supavisor are definitely the new kids on the block.

@Binidxaba666 4 ай бұрын

Author here. Correct, that's one of the reasons. Another reason was to narrow down the scope of the investigation. Consider that just as PgPool could have been another option, so could have been PgAgroal and Odyssey. Thanks for your interest in the blog post! @@ScalingPostgres