Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 0513F733E23 for ; Sat, 10 Dec 2011 23:11:35 -0400 (AST) Received: from [2001:1528:137::f1] (helo=mail.gransy.com) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RZZp8-0006hs-6C for pgsql-performance@postgresql.org; Sun, 11 Dec 2011 03:11:34 +0000 Received: from antispam.gransy.com (antispam.gransy.com [77.78.104.124]) by mail.gransy.com (Postfix) with ESMTP id 0DAC44A209D for ; Sun, 11 Dec 2011 04:11:21 +0100 (CET) Received: from mail.gransy.com ([82.208.29.194]) by antispam.gransy.com (antispam.gransy.com [77.78.104.124]) (amavisd-new, port 10024) with ESMTP id 17P2FzYUmiKh for ; Sun, 11 Dec 2011 04:11:20 +0100 (CET) Received: from [192.168.1.237] (ip-78-45-133-255.net.upcbroadband.cz [78.45.133.255]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id E63854A2007 for ; Sun, 11 Dec 2011 04:11:20 +0100 (CET) Message-ID: <4EE41F5A.60305@fuzzy.cz> Date: Sun, 11 Dec 2011 04:11:22 +0100 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Common slow query reasons - help with a special log References: <4EE39620.5020703@fuzzy.cz> <4EE3F060.6000602@fuzzy.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2001:1528:137::f1 (failed) X-Pg-Spam-Score: -1.1 (-) X-Archive-Number: 201112/90 X-Sequence-Number: 45889 On 11.12.2011 02:27, Daniel Cristian Cruz wrote: > I would start with 5 seconds. > > Reading the manual again and I saw that enabling analyze, it analyze all > queries, even the ones that wasn't 5 second slower. And understood that > there is no way to disable for slower queries, since there is no way to > know it before it ends... Yes, you can't predict how long a query will run until it actually finishes, so you have to instrument all of them. Maybe this will change because of the "faster than light" neutrinos, but let's stick with the current laws of physics for now. > I read Bruce blog about some features going to multi-core. Could explain > analyze go multi-core too? I don't think so. This is what Bruce mentioned as "parallel execution" and that's the very hard part requiring rearchitecting parts of the system. > Another thing I saw is that I almost never look at times in explain > analyze. I always look for rows divergence and methods used for scan and > joins when looking for something to get better performance. > > I had the nasty idea of putting a // before de gettimeofday in the code > for explain analyze (I guess it could be very more complicated than this). I was thinking about that too, but I've never done it. So I'm not sure what else is needed. Tomas