{"issue":{"state":"closed","created_at":"2011-12-05T19:27:00Z","updated_at":"2011-12-06T04:11:04Z","user":{"gravatar_id":"018c63c67c32ee0b29105dd111e96bc3","id":167022,"url":"https://api.github.com/users/jadeforrest","login":"jadeforrest","avatar_url":"https://secure.gravatar.com/avatar/018c63c67c32ee0b29105dd111e96bc3?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png"},"comments":9,"body":"At New Relic, we have hundreds of thousands of tables, and our migrations took 30 minutes without a similar patch. This cuts it down to a more reasonable amount of time. The more tables you have, the more efficiency gain you derive from the patch.\r\n\r\nThe rescue false part is ugly, but necessary as far as I can tell. I don't know of a cross-database statement you can make that will work without trapping and relying on errors.\r\n\r\nTested on MySQL and SQLite, but I believe this should work across any database.","assignee":null,"number":3867,"id":2453347,"labels":[],"pull_request":{"patch_url":"https://github.com/rails/rails/pull/3867.patch","html_url":"https://github.com/rails/rails/pull/3867","diff_url":"https://github.com/rails/rails/pull/3867.diff"},"title":"Increase performance for table_exists?","html_url":"https://github.com/rails/rails/issues/3867","closed_at":"2011-12-05T22:15:51Z","url":"https://api.github.com/repos/rails/rails/issues/3867","milestone":null},"action":"created","comment":{"created_at":"2011-12-06T04:11:04Z","updated_at":"2011-12-06T04:11:04Z","user":{"gravatar_id":"018c63c67c32ee0b29105dd111e96bc3","id":167022,"url":"https://api.github.com/users/jadeforrest","login":"jadeforrest","avatar_url":"https://secure.gravatar.com/avatar/018c63c67c32ee0b29105dd111e96bc3?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png"},"body":"Thank you for testing it on Postgres!\r\n\r\nSent from my iPhone\r\n\r\nOn Dec 5, 2011, at 8:06 PM, Jon Jensen<reply@reply.github.com> wrote:\r\n\r\n> i've confirmed this is fine for postgres (9.0+ anyway) ... the query planner applies the false condition filter before it ever scans any rows, so execution time should always be extremely fast (<0.1ms in my tests)\r\n> \r\n> --- \r\n> Reply to this email directly or view it on GitHub:\r\n> https://github.com/rails/rails/pull/3867#issuecomment-3027986","id":3028011,"url":"https://api.github.com/repos/rails/rails/issues/comments/3028011"}}