Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1ToJ0v-0000fS-17 for pgsql-performance@arkaria.postgresql.org; Thu, 27 Dec 2012 19:21:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1ToJ0t-0005fs-US for pgsql-performance@arkaria.postgresql.org; Thu, 27 Dec 2012 19:21:07 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1ToJ0s-0005fn-Ut for pgsql-performance@postgresql.org; Thu, 27 Dec 2012 19:21:07 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1ToJ0o-0008VR-7M for pgsql-performance@postgresql.org; Thu, 27 Dec 2012 19:21:06 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id qBRJL1i8017230; Thu, 27 Dec 2012 14:21:01 -0500 (EST) From: Tom Lane To: Nikolas Everett cc: "pgsql-performance@postgresql.org" Subject: Re: explain analyze reports that my queries are fast but they run very slowly In-reply-to: References: Comments: In-reply-to Nikolas Everett message dated "Thu, 27 Dec 2012 12:10:11 -0500" Date: Thu, 27 Dec 2012 14:21:00 -0500 Message-ID: <17229.1356636060@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) 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 Nikolas Everett writes: > We just upgraded from 8.3 to 9.1 and we're seeing some performance > problems. When we EXPLAIN ANALYZE our queries the explain result claim > that the queries are reasonably fast but the wall clock time is way way > longer. Does anyone know why this might happen? > Like so: > db=>\timing > db=>EXPLAIN ANALYZE SELECT max(id) FROM foo WHERE blah_id = 1209123; > The plan is sensible. The estimates are sensible. The actual DB time > reads like it is very sensible. But the wall clock time is like 11 seconds > and the \timing report confirms it. Seems like the extra time would have to be in parsing/planning, or in waiting to acquire AccessShareLock on the table. It's hard to believe the former for such a simple query, unless the table has got thousands of indexes or something silly like that. Lock waits are surely possible if there is something else contending for exclusive lock on the table, but it's hard to see how the wait time would be so consistent. BTW, the explain.depesz.com link you posted clearly does not correspond to the above query (it's not doing a MAX), so another possibility is confusion about what query is really causing trouble. We've seen people remove essential details before while trying to anonymize their query. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance