2010-09-21 14 views
6

कुछ MySQL विशिष्ट प्रश्नों को हटाने के अलावा, माइग्रेशन बहुत चिकनी था। अब समस्या यह है कि विकास के दौरान पहले डीबी से बहुत अधिक प्रश्न हैं।रेल पर MySQL से पोस्टग्रेस तक चल रहा है 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 

ऊपर की तरह 3-8 अतिरिक्त प्रश्नों में हर एक क्वेरी परिणाम। क्या और क्यों हो रहा है? अब समस्याओं में से एक यह है कि developement.log फूला हुआ और अपठनीय है। मैं समय का भार उन प्रश्नों सही काम की तलाश में inbetween स्क्रॉल ... बर्बाद

अद्यतन: मंगल सितं, 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

कथन उत्पन्न करने वाली क्वेरी पोस्ट करें। आप शायद कुछ MySQL- उन्मुख कोड का उपयोग कर रहे हैं। –

+1

मामला नहीं, प्रश्न में स्पष्टीकरण जोड़ा गया। – mdrozdziel

उत्तर

4

मैंने इसे किसी अन्य पोस्ट से चुरा लिया: हो सकता है कि आप http://github.com/dolzenko/silent-postgres पर एक नज़र डालें, वह प्लगइन उन प्रश्नों को स्ट्रिप करता है। उन लॉग शोर उच्च postgresql लॉग स्तर की वजह से होता है।

+0

यह एक आकर्षण की तरह काम करता है, धन्यवाद! – mdrozdziel

1

दूसरा क्वेरी अपने आवेदन के द्वारा प्रयोग किया जाता है पाने के लिए इस्तेमाल किए गए डेटाटाइप के बारे में जानकारी और यह देखने के लिए कि कॉलम शून्य है या नहीं। यदि आप pgAdmin3 का उपयोग कर रहे हैं तो आप परिणामों के मेटा डेटा प्राप्त करने के लिए, इन प्रकार के प्रश्नों को भी देखेंगे। अधिकांश अनुप्रयोगों को इस तरह के प्रश्नों की आवश्यकता नहीं होती है, यह ज्यादातर विकास के दौरान और pgAdmin जैसे उपकरणों के लिए उपयोगी है।

+0

ठीक है, लेकिन विकास के दौरान इसे अक्षम करने का कोई तरीका है। मैं अब अपने लॉग का पता नहीं लगा सकता। यह वास्तव में परेशान हो रहा है ... – mdrozdziel

+0

postgresql.conf संपादित करें और log_min_duration_statement 1000 पर सेट करें। 1000 = 1000 मिलीसेकंड, 1 सेकंड। आप log_min_error_statement को ERROR पर भी सेट कर सकते हैं। आपको superger के रूप में postgresql.conf को पुनः लोड करना होगा: pg_reload_conf() चुनें; आप अपने डेटाबेससेवर को भी पुनरारंभ कर सकते हैं। –

संबंधित मुद्दे