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.

Currently in Odyssey password_passthrough works only for cleartext auth, PAM and LDAP. Probably, we could make this for MD5 work too. And it's the whole purpose of SCRAM to defeat this feature :)

The other way to do so is auth_query - you provide a storage password to access auth data of the DB. This works for MD5 auth. When user wants to authenticate we just check credentials against what we see in the database.

Hmm, yes. ParameterStatus is not sent when search_path is changed. But I think it would be trivial to patch PostgreSQL to send it. I bet one even can push such patch through commitfest.

No. It's just about developer experience. PostgreSQL core developemnt under MacOS is just so great. You can develop PG patches completely without internet connection on a very old MacBook Air. And everything will be so blazingly fast. For Odyssey development MacOS user needs VM, Linux box or Docker.

I'd certainly recommend to run pooler on the same node to avoid double encryption. Reestablishing 2x connections, dealing with 2x restarts of VM - is kind of a downside too. However it's not strictly neccesary, Odyssey can run even in another AZ :)

We are also developing managed databases for US\EU market https://double.cloud/

Sure. We use Odyssey as a component of HA cluster in Yandex.Cloud. Odyssey runs on each node of a Patroni-like system. One day we want to implement load balancing functionality in Odyssey. So that your queries go to other node if local is overloaded or lagging long behind primary.

Yes, that's a problem. We use Docker only for developement. And mostly because Odyssey is based on epoll and just will not compile on MacOS.

Depends on how you measure performance :) pgagroal utilizes a lot of linux processes to track each connection state, we use coroutines packed into small number of processes. Actually if you have a bottleneck in multithreaded pooler - something really goes wrong. The database should consume most of resources. I'd be happy to help tuning Odyssey to someone who will bachmark both poolers (in fact there's only one number - number of worker processes..well, maybe pool_size too).

pgagroal claims performance superiority over all poolers [0]. I doubt that Odyssey was used in transaction pooling mode in those experiments.

[0] https://github.com/agroal/pgagroal/blob/master/doc/PERFORMAN...