x4m

Was a flight to space an iteration?

As Odyssey maintainer, I have to admit that it is exceptionally difficult to achieve stability (e.i. quality) of PgBouncer.

It has two limitations: it is single threaded and it is developed only re-actively. PgBouncer docs used to say that prepared statements can never be supported, in 2022 we supported it in Odyssey and then PgBouncer implemented it too.

In a sense Odyssey is developed to motivate PgBouncer development. To provide alternatives that keep PgBouncer from stagnation.

Yet, I can't say that scalability with SO_REUSEPORT is a good solution.

With Odyssey we have customers with 50k+ connections operating normally.

Also consider SQPR - it's a connection pooler with sharding capabilities. It handles data migration between shard on top of request routing. Odyssey will inherit this capability once it is stable enough in functions set.

Just use https://github.com/yandex/odyssey :) It's a scalable PgBouncer.

I'd love to! But MySQL is developed inside Oracle, and OCA somewhat scares me. Perhaps, I'll give a try to MariaDB or other forks.

And there's also https://postgrespro.com/docs/enterprise/current/multimaster With a history behind it.

I think this should run just fine, why not? As long as you have proper Postgres operator, such proxy will run normally on top of that.

+1

there's already well maintained extension https://github.com/fboulnois/pg_uuidv7

It's slightly different from recommendations by draft RFC version (there's no counter), but fully within spec requirements. From practical point there's no difference at all.

FWIW Steam Deck runs 8k transactions per second if you build Postgres there. A nice place to work on open source development, actually. https://twitter.com/x4mmmmmm/status/1620984546216017921

> Reduce the memory usage of prepared queries

FWIW Odyssey supports prepared statements in transaction pooling.

I concur that Odyssey docs are insufficient to build a big picture. But I'm trying to answer every question in the Internets about Odyssey :) Documenting is hard - everything seems obvious to me, but understand that may things are not that obvious. // Odyssey maintainer

I think the book is free because Egor and PostgresPro want to develop the community. If you want to pay back - you can just start contributing to Postgres. No need to wait :)

You are running on up to date version which seems to have no known critical bugs.

Just revert d9d0762 or use actual REL_14_STABLE.

Transaction pooling rules are equivalent in Odyssey and PgBouncer.

It seems like there's issue when you have a user for accessing authentication table you login with the same user. It fails when due to mixing same pool for auth and for work. I'll look into differentiating these pools more closely. As a simple workaround you can setup different user for accessing password and not login into Odyssey with this user.

Odyssey could work fine on arm, but we've a small ASM function https://github.com/yandex/odyssey/blob/master/third_party/ma... . We need to reimplement it for ARM64 or at least fallback on some generic context swap.

Odyssey stands before the databases and packs thousands of NodeJS connection into few tens of real server connections.

I'm not actually aware of all detailed plans. My job is to advance PostgreSQL ecosystem. But I'll pass a question to someone with broader view.

I think there's a lot of different HA solutions - Patroni, Stolon, Pacemaker to name few.

I heard FAANG is now MANGA :)

There's already working part of libpq protocol for this - target_session_attrs. But the problem with target_session_attrs is that it just takes too long to discover new primary after failolver. We want to fix this within Odyssey.