Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id B5CD064FD16 for ; Thu, 20 Nov 2008 06:45:59 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 04177-09 for ; Thu, 20 Nov 2008 06:45:56 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from pih-relay08.plus.net (pih-relay08.plus.net [212.159.14.20]) by mail.postgresql.org (Postfix) with ESMTP id C508F64FC5A for ; Thu, 20 Nov 2008 06:45:56 -0400 (AST) Received: from [84.51.143.99] (helo=server3.office.archonet.com) by pih-relay08.plus.net with esmtp (Exim) id 1L372o-0007fU-6Y; Thu, 20 Nov 2008 10:45:54 +0000 Received: from [192.168.1.36] (dell36.office.archonet.com [192.168.1.36]) by server3.office.archonet.com (Postfix) with ESMTP id F2E21274051; Thu, 20 Nov 2008 10:45:53 +0000 (GMT) Message-ID: <49253FE1.3070706@archonet.com> Date: Thu, 20 Nov 2008 10:45:53 +0000 From: Richard Huxton User-Agent: Thunderbird 2.0.0.18 (X11/20081105) MIME-Version: 1.0 To: Andrus CC: pgsql-performance@postgresql.org Subject: Re: Hash join on int takes 8..114 seconds References: In-Reply-To: Content-Type: text/plain; charset=windows-1257 Content-Transfer-Encoding: 7bit X-Plusnet-Relay: 35c2cbfe70c155c931bc27faf1786e94 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200811/174 X-Sequence-Number: 31905 Andrus wrote: > Query below seems to use indexes everywhere in most optimal way. > dokumnr column is of type int > > Speed of this query varies rapidly: > > In live db fastest response I have got is 8 seconds. > Re-running same query after 10 seconds may take 60 seconds. > Re-running it again after 10 seconds may take 114 seconds. > > Any idea how to speed it up ? > > Is it possible to optimize it, will upgrading to 8.3.5 help or should I > require to add more RAM, disk or CPU speed ? At a quick glance, the plans look the same to me. The overall costs are certainly identical. That means whatever is affecting the query times it isn't the query plan. > "Aggregate (cost=234278.53..234278.54 rows=1 width=0) (actual > time=62164.496..62164.500 rows=1 loops=1)" > "Total runtime: 62164.789 ms" > "Aggregate (cost=234278.53..234278.54 rows=1 width=0) (actual > time=40185.499..40185.503 rows=1 loops=1)" > "Total runtime: 40186.102 ms" > "Aggregate (cost=234278.53..234278.54 rows=1 width=0) (actual > time=29650.398..29650.402 rows=1 loops=1)" > "Total runtime: 29650.696 ms" > "Aggregate (cost=234278.53..234278.54 rows=1 width=0) (actual > time=11131.392..11131.396 rows=1 loops=1)" > "Total runtime: 11131.694 ms" So - what other activity is happening on this machine? Either other queries are taking up noticeable resources, or some other process is (it might be disk activity from checkpointing, logging some other application). -- Richard Huxton Archonet Ltd