Помимо удаления некоторых специфичных для MySQL запросов, миграция была довольно плавной. Проблема сейчас в том, что во время разработки к БД поступает гораздо больше запросов, чем раньше.
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 дополнительным запросам, как указано выше. Что и почему происходит? Одна из проблем сейчас заключается в том, что development.log раздутый и нечитаемый. Я трачу кучу времени на прокрутку между этими запросами в поисках нужной вещи ...
Обновление: вт 21 сентября
Это не связано с типом запроса. Все запросы генерируют этот тип штуковины:
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>