除了删除一些特定于MySQL的查询之外,迁移非常顺利。现在的问题是,在开发过程中,对DB的查询比以前多得多。
Started GET "/profiles/data" for 127.0.0.1 at Tue Sep 21 10:26:18 +0200 2010
Processing by ProfilesController#data as JSON
User Load (24.3ms) SELECT "users".* FROM "users" ORDER BY updated_at DESC LIMIT 1
CACHE (0.0ms) SELECT "users".* FROM "users" ORDER BY updated_at DESC LIMIT 1
SQL (10.5ms) SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc, a.attnotnull
FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = '"users"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum
每个查询都会产生3-8个额外的查询,如上所述。什么和为什么发生?现在的问题之一是,developement.log臃肿且难以理解。我浪费大量时间在那些查找正确的查询之间滚动...
更新:9月21日星期二
这与查询类型无关。所有的查询都产生了这种stuph:
ree-1.8.7-2010.02 > User.first
SQL (0.3ms) SHOW client_min_messages
SQL (2.0ms) SET client_min_messages TO 'panic'
SQL (6.3ms) SET standard_conforming_strings = on
SQL (18.3ms) SET client_min_messages TO 'notice'
SQL (15.6ms) SET time zone 'UTC'
SQL (17.2ms) SHOW TIME ZONE
SQL (23.8ms) SELECT tablename FROM pg_tables WHERE schemaname = ANY (current_schemas(false))
User Load (162.4ms) SELECT "users".* FROM "users" LIMIT 1
SQL (7.5ms) SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc,
a.attnotnull FROM pg_attribute a LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid
AND a.attnum = d.adnum WHERE a.attrelid = '"users"'::regclass AND a.attnum > 0 AND
NOT a.attisdropped ORDER BY a.attnum
[...] 1排成套 ree-1.8.7-2010.02>
答案 0 :(得分:4)
我从另一篇文章中偷了这个:你可能想看一下http://github.com/dolzenko/silent-postgres该插件将这些查询删除掉。由于postgresql日志级别较高,会发生这些日志噪音。
答案 1 :(得分:1)
应用程序使用第二个查询来获取有关所用数据类型的信息,并查看该列是否可为空。如果你正在使用pgAdmin3,你会看到很多这类查询,只是为了得到结果的元数据。大多数应用程序不需要这样的查询,它在开发期间和pgAdmin等工具中非常有用。