-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simple query runs long when DB schema contains thousands of tables #186
Comments
Yes, seems to be a pathology in the type introspection query. |
Stop using CTEs in the type introspection query, otherwise it runs for ages on databases with a large number of composite attributes (i. e. tons of tables with tons of columns). Fixes: #186
@elprans, I tested your fix. Now it's blazing fast. Thank you for quick fixing! |
I'm having the same issue with the last version of asyncpg (0.19.0). Still thinking on how to reproduce it and share. |
@shvechikov Are you running postgres with |
I'm on asyncpg (0.19.0) and also still seeing this in my
|
It doesn't seem to actually be slow for you. |
Ahhhh, I thought that was the time taken by the query planner! Turns out |
uvloop?: yes
My DB schema contains thousands of tables inherited from one table. These tables store some logs or historical information and have around 100 columns. As a result, PostgreSQL information schema table
pg_attribute
contains enormous number of records.I use my own DB user
sergey
to connect to PostgreSQL who is a superuser. When I connect as this user, some simple queries run very long in asyncpg.Preparation. This code creates 5000 inherited tables with 100 columns to prepare similar environment for the test cases below:
Example 1: Connect as
sergey
and run this simple query:While it was running for about 2 minutes, I saw this query in
pg_activity_stat
:Unfortunately,
pg_activity_stat
does not show the whole query but only first part. I guess the slow execution has to do with the size ofpg_attribute
.Example 2: Now connect as user
postgres
and run the same query. It is still not instant but much faster (~1 second):Example 3: Not all queries execute long. This one is fast:
P.S. I tried
vacuum full analyze pg_attribute
andvacuum full analyze pg_class
, it did not help.The text was updated successfully, but these errors were encountered: