Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VqU6M-0001Y1-GO for pgsql-performance@arkaria.postgresql.org; Tue, 10 Dec 2013 20:40:18 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VqU6L-0003si-Uj for pgsql-performance@arkaria.postgresql.org; Tue, 10 Dec 2013 20:40:17 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VqU6K-0003rR-RH for pgsql-performance@postgresql.org; Tue, 10 Dec 2013 20:40:16 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VqU6E-0007Io-Mk for pgsql-performance@postgresql.org; Tue, 10 Dec 2013 20:40:16 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1VqU6D-00039i-DR; Tue, 10 Dec 2013 15:40:09 -0500 Date: Tue, 10 Dec 2013 15:40:09 -0500 From: Bruce Momjian To: Tom Lane Cc: salah jubeh , "pgsql-performance@postgresql.org" Subject: Re: Explain analyze time overhead Message-ID: <20131210204009.GA14636@momjian.us> References: <1386252540.32882.YahooMailNeo@web122206.mail.ne1.yahoo.com> <14363.1386253334@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <14363.1386253334@sss.pgh.pa.us> User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -2.1 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Thu, Dec 5, 2013 at 09:22:14AM -0500, Tom Lane wrote: > salah jubeh writes: > > When I excute a query,  the exection time is about 1 minute; however, when I execute the query with explain analyze the excution time jumps to 10 minutes. > > This isn't exactly unheard of, although it sounds like you have a > particularly bad case. Cheap commodity PCs tend to have clock hardware > that takes multiple microseconds to read ... which was fine thirty years > ago when that hardware design was set, but with modern CPUs that's > painfully slow. > > Short of getting a better machine, you might look into whether you can run > a 64-bit instead of 32-bit operating system. In some cases that allows > a clock reading to happen without a context switch to the kernel. > > > This is a little bit starnge for me; did any one experience somthing like this? Can I trust the generated plans? > > The numbers are fine as far as they go, but you should realize that the > relative cost of the cheaper plan nodes is being overstated, since the > added instrumentation cost is the same per node call regardless of how > much work happens within the node. The original poster might also want to run pg_test_timing to get hardware timing overhead: http://www.postgresql.org/docs/9.3/static/pgtesttiming.html -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance