asyncpg VS ruby

- SqlAlchemy/asyncpg => you can’t use it if you’re using PgBouncer (necessary most of the time with Postgres) in transaction mode? What?? https://github.com/MagicStack/asyncpg/issues/1058

OK I stand corrected, asyncpg has these two C files:

https://github.com/MagicStack/asyncpg/blob/master/asyncpg/pr...

https://github.com/MagicStack/asyncpg/blob/master/asyncpg/pr...

If you are interested here is a post by the psycopg author about psycopg2 and 3 and performance versus asyncpg.

https://www.varrazzo.com/blog/2020/05/19/a-trip-into-optimis...

This pure Python library claims quite fabulous performance: https://github.com/MagicStack/asyncpg

I believe it because that team have done lots of great stuff but I haven't used it, I just remembered thinking it was interesting the performance was so good. Not sure how related it is to running on the asyncio loop (or which loop they used for benchmarks).

what a great post, we have had a ton of issues with users using pgbouncer and it's not because things are "broken" per se, it's just the situation is very complicated, and pgbouncer's docs are also IMO in need of updating to be more detailed and in a few critical cases less misleading, specifically the prepared statements docs.

This blog post refers to this misleading nature at https://jpcamara.com/2023/04/12/pgbouncer-is-useful.html#pre... .

> PgBouncer says it doesn’t support prepared statements in either PREPARE or protocol-level format. What it actually doesn’t support are named prepared statements in any form.

That's also not really accurate. You can use a named prepared statement just fine in transaction mode. start a transaction (so you aren't in autocommit), use a named statement, works fine. you just can't use it again in another transaction, because it will be "gone" (more accurately, "unmoored" - might be in your session, might be in someone else's session). Making things worse, when the prepared statement is "unmoored", its name can then conflict with another client attempting to use the same name.

so to use named prepared statements, you can less ideally name them with random strings to avoid conflicts, or you can DEALLOCATE the prepared statement(s) you used at the end of your transaction. for our users that use asyncpg, we have them use a uuid for prepared statements to avoid these name conflicts (asyncpg added this feature for us here: https://github.com/MagicStack/asyncpg/issues/837). however, they can just as well use DEALLOCATE ALL, set this as their `server_reset_query`, and then so that happens in transaction mode, also set `server_reset_query_always`, so that it's called at the end of transactions. Where pgbouncer here IMO entirely misleadingly documents this as "This setting is for working around broken setups that run applications that use session features over a transaction-pooled PgBouncer." - which is why nobody uses it, because pgbouncer claims this is "broken". It's not any more broken than it is to switch out the PostgreSQL session underneath a connection that uses multiple transactions. Pgbouncer can do better here and make this clearer and more accommodating of real world database drivers.

asyncpg is another great driver if you're using asyncio and want maximum performance (although they also break with DBAPI, but the tradeoff may be worth it).

asyncpg: 5.5k starts, last commit recently, ~150 issues, some incompatibility, few open PRs, extensive README. Includes benchmark showing it's supposedly 3x faster than aiopg and psycopg2, psycopg3 is not mentioned in the benchmark.

Quart-DB uses asyncpg to manage the connections and buildpg to parse the named parameter bindings.

A major performance boost specifically on inserts with timescaledb was actually starting to use https://github.com/MagicStack/asyncpg.

Simple query runs long when DB schema contains thousands of tables #186

To create a new Rails app, you should have Ruby and Rails installed on your machine. You can find how to install Ruby on your local machine using the Ruby docs. You can install Rails by running the following command:

Ruby testing with RSpec

Not parent poster and do not have production YJIT experience. =)

My guess is that you would monitor `RubyVM::YJIT.runtime_stats[:code_region_size]` and/or `RubyVM::YJIT.runtime_stats[:code_gc_count]` so that you can get a feel for a reasonable value for your application, as well as know whether or not the "code GC" is running frequently.

https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#pe...

Link to the commit

Part of the major userbase pull in GitHub revolves around hosting a considerable number of popular projects including Angular, React, Kubernetes, cpython, Ruby, tensorflow, and well even the software that powers this site Forem.

Hold option and click on the “collapse file” button in the Files view of a commit or pull request, and it will collapse all the files.

Select text in a comment, issue, or pull request description and press r—the selected text (including markdown formatting) will get pre-populated as a markdown block quote reply in the next comment box.

Add .patch or .diff to any pull request URL if you want to see a plain-text diff of the pull request (e.g. maybe you want to quickly `curl ... | git apply -` an unmerged pull request into a local copy of the repo without trying to add and fetch the git remote that the pull request is from).

There are lots of keyboard shortcuts. For example, / to jump to the file finder.

Not so much a secret but more like a hiding in plain sight: when looking at a commit GitHub will show you the earliest and latest tag (i.e. release) that includes the commit. For example, this commit[1] first appeared in v3_2_0_preview3.

[1]: https://github.com/ruby/ruby/commit/892f350a7db4d2cc99c5061d...

The title is misleading, just like other commenters mentioned. Just check how much indirection "rb_iv_get()" has to make (at the end, it will call [1], which isn't "a light" call). Now, check generated JIT code (in a blog post) for the same action where JIT knows how to shave off unnecessary indirection.

We are comparing apples and oranges here.

[1] https://github.com/ruby/ruby/blob/b635a66e957e4dd3fed83ef1d7...

I'm not sure why, but all the source values are listed here: https://github.com/ruby/ruby/blob/1cc700907d3ad3368272488a6f...

Maybe someone knowledgeable in the underpinnings of Ruby will explain why "class variable" was not hyphenated.