{"action":"created","issue":{"url":"https://api.github.com/repos/sqlalchemy-redshift/sqlalchemy-redshift/issues/101","repository_url":"https://api.github.com/repos/sqlalchemy-redshift/sqlalchemy-redshift","labels_url":"https://api.github.com/repos/sqlalchemy-redshift/sqlalchemy-redshift/issues/101/labels{/name}","comments_url":"https://api.github.com/repos/sqlalchemy-redshift/sqlalchemy-redshift/issues/101/comments","events_url":"https://api.github.com/repos/sqlalchemy-redshift/sqlalchemy-redshift/issues/101/events","html_url":"https://github.com/sqlalchemy-redshift/sqlalchemy-redshift/issues/101","id":188034124,"number":101,"title":"Constraint information is not being cached","user":{"login":"atrigent","id":1234297,"avatar_url":"https://avatars.githubusercontent.com/u/1234297?v=3","gravatar_id":"","url":"https://api.github.com/users/atrigent","html_url":"https://github.com/atrigent","followers_url":"https://api.github.com/users/atrigent/followers","following_url":"https://api.github.com/users/atrigent/following{/other_user}","gists_url":"https://api.github.com/users/atrigent/gists{/gist_id}","starred_url":"https://api.github.com/users/atrigent/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/atrigent/subscriptions","organizations_url":"https://api.github.com/users/atrigent/orgs","repos_url":"https://api.github.com/users/atrigent/repos","events_url":"https://api.github.com/users/atrigent/events{/privacy}","received_events_url":"https://api.github.com/users/atrigent/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-11-08T16:11:57Z","updated_at":"2016-11-08T17:30:12Z","closed_at":null,"body":"In `RedshiftDialect`, there are three methods, `_get_all_relation_info`, `_get_all_column_info`, and `_get_all_constraint_info`, which query information about the whole cluster. These methods are called by several other methods which pass their `info_cache` argument down to one of the above methods. These methods, in turn, are called by other methods which, in most cases, pass down all of their keyword arguments. The one exception is `_get_redshift_constraints` - this method is never called with the keyword arguments of its caller, and therefore never gets the `info_cache` object that was passed in by SQLAlchemy. The result of this is that constraint information is never cached. When running something like alembic which does a lot of reflection, this can slow things down considerably because the dialect winds up querying information about the entire database every time alembic asks for anything."},"comment":{"url":"https://api.github.com/repos/sqlalchemy-redshift/sqlalchemy-redshift/issues/comments/259202877","html_url":"https://github.com/sqlalchemy-redshift/sqlalchemy-redshift/issues/101#issuecomment-259202877","issue_url":"https://api.github.com/repos/sqlalchemy-redshift/sqlalchemy-redshift/issues/101","id":259202877,"user":{"login":"atrigent","id":1234297,"avatar_url":"https://avatars.githubusercontent.com/u/1234297?v=3","gravatar_id":"","url":"https://api.github.com/users/atrigent","html_url":"https://github.com/atrigent","followers_url":"https://api.github.com/users/atrigent/followers","following_url":"https://api.github.com/users/atrigent/following{/other_user}","gists_url":"https://api.github.com/users/atrigent/gists{/gist_id}","starred_url":"https://api.github.com/users/atrigent/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/atrigent/subscriptions","organizations_url":"https://api.github.com/users/atrigent/orgs","repos_url":"https://api.github.com/users/atrigent/repos","events_url":"https://api.github.com/users/atrigent/events{/privacy}","received_events_url":"https://api.github.com/users/atrigent/received_events","type":"User","site_admin":false},"created_at":"2016-11-08T17:30:12Z","updated_at":"2016-11-08T17:30:12Z","body":"I think your approach of doing just a few queries actually does work. You're right that the reflection methods that make up the public interface of the dialect generally require a table name, and that caching the result of those methods by itself won't reduce the number of queries that you have to make, but caching the result of your `_get_all_*` methods, which return information about the whole database, does definitely speed things up considerably. With the change you made in PR #102, a test that we have for making sure that our migrations are up to date goes from 2+ minutes to about 3 seconds."}}
{"actor":{"display_login":"atrigent"}}