Pasar de MySQL a Postgres en Rails 3

Además de eliminar algunas consultas específicas de MySQL, la migración fue bastante fluida. El problema ahora es que durante el desarrollo hay muchas más consultas al DB que antes.Pasar de MySQL a Postgres en Rails 3

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

Cada consulta individual tiene como resultado entre 3 y 8 consultas adicionales como la anterior. ¿Qué y por qué está pasando? Uno de los problemas ahora es que developement.log está hinchado e ilegible. Pierdo un montón de tiempo de desplazamiento entre medio de las consultas en busca de lo correcto ...

Actualización: 21 mar

septiembre Esto no está relacionado con el tipo de consulta. Todas las consultas están generando este tipo de 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 row in set ree-1.8.7-2010.02>

Fuente

2010-09-21 mdrozdziel

Publique la consulta que genera la instrucción. Probablemente estés usando algún código orientado a MySQL. –

No es el caso, explicación agregada a la pregunta. – mdrozdziel

Lo robé de otra publicación: es posible que desee echar un vistazo a http://github.com/dolzenko/silent-postgres Ese complemento quita esas consultas. Esos ruidos de registro ocurren debido al alto nivel de registro postgresql.

Fuente

2010-09-22 01:34:03 baldmark

Esto funciona como un encanto, ¡gracias! – mdrozdziel

La segunda consulta es utilizado por la aplicación para obtener información sobre el tipo de datos utilizado y para ver si la columna es nula o no. Si está usando pgAdmin3, verá mucho este tipo de consultas también, solo para obtener metadatos de los resultados. La mayoría de las aplicaciones no necesitan consultas como esta, es más útil durante el desarrollo y para herramientas como pgAdmin.

Fuente

2010-09-21 10:09:48

Bien, pero ¿hay alguna manera de desactivar esto durante el desarrollo? No puedo rastrear mi registro más ahora. Es realmente molesto ... – mdrozdziel

Edite postgresql.conf y establezca log_min_duration_statement en 1000. 1000 = 1000 milisegundos, 1 segundo. También podría establecer log_min_error_statement en ERROR. Tienes que volver a cargar postgresql.conf como superusuario: SELECT pg_reload_conf(); También puede reiniciar su servidor de base de datos. –

Pasar de MySQL a Postgres en Rails 3

Respuesta

Cuestiones relacionadas