在Rails/Heroku上对Postgres数据库的意外SQL查询

cor*_*ard 12 sql postgresql ruby-on-rails heroku newrelic

我正在使用NewRelic向我的一个Rails应用程序发出一个非常长的请求,发现许多SQL查询看起来完全是外来的,占用了相当长的时间.我已经谷歌了,但我已经空手而归,不管我是否可以防止它们发生.

SELECT COUNT(*) FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind in (?, ?) AND c.relname = ? AND n.nspname = ANY (current_schemas(false))
Run Code Online (Sandbox Code Playgroud)

…和…

SELECT a.attname, format_type(a.atttypid, a.atttypmod), pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod FROM pg_attribute a LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum WHERE a.attrelid = ?::regclass AND a.attnum > ? AND NOT a.attisdropped ORDER BY a.attnum
Run Code Online (Sandbox Code Playgroud)

...每次发生7次,共计145ms和135ms.

SELECT DISTINCT(attr.attname) FROM pg_attribute attr INNER JOIN pg_depend dep ON attr.attrelid = dep.refobjid AND attr.attnum = dep.refobjsubid INNER JOIN pg_constraint cons ON attr.attrelid = cons.conrelid AND attr.attnum = cons.conkey[?] WHERE cons.contype = ? AND dep.refobjid = ?::regclass
Run Code Online (Sandbox Code Playgroud)

......以104毫秒的成本进行了2次,并且......

SHOW search_path
Run Code Online (Sandbox Code Playgroud)

...一次通话命令45ms.

我的直觉说这些与Postgres Rails适配器有关,但是我不明白是什么触发了它们或者它们正在做什么,或者(更重要的是)它们在典型请求中被解雇的原因.


我只是更彻底地检查了日志,看起来这个请求运行的Dyno在几秒钟前已经转换为"up",所以很可能这个请求是第一个.

小智 9

表pg_class,pg_attribute,pg_depend等都描述了postgres中的表,列和依赖项.在Rails中,模型类由表定义,因此Rails读取表和列以确定每个模型的属性.

在开发模式下,它会在每次访问模型时查找这些值,因此如果您最近发生了变化,Rails就会知道它.在生产模式下,Rails会缓存它,因此您可以更频繁地看到这些,因此它确实不是一个问题.