Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id F00B71337B61 for ; Wed, 12 Jan 2011 11:20:41 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 32782-01 for ; Wed, 12 Jan 2011 15:20:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from 10610.x.rootbsd.net (10610.x.rootbsd.net [204.109.60.69]) by mail.postgresql.org (Postfix) with ESMTP id 807E11336971 for ; Wed, 12 Jan 2011 11:20:34 -0400 (AST) Received: from [192.168.10.101] (localhost [127.0.0.1]) by 10610.x.rootbsd.net (8.14.3/8.14.3) with ESMTP id p0CFM8E5071355; Wed, 12 Jan 2011 15:22:09 GMT (envelope-from gandalf@shopzeus.com) Message-ID: <4D2DC6BA.3000400@shopzeus.com> Date: Wed, 12 Jan 2011 16:20:26 +0100 From: Laszlo Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Kevin Grittner CC: Florian Weimer , Daniel Fekete , "pgsql-performance@postgresql.org" Subject: Re: Slow query + why bitmap index scan?? References: <4D2D9B1E.7080302@shopzeus.com> <82y66qp7al.fsf@mid.bfk.de> <4D2DB8F9.9050609@shopzeus.com> <4D2D68270200002500039327@gw.wicourts.gov> In-Reply-To: <4D2D68270200002500039327@gw.wicourts.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201101/72 X-Sequence-Number: 41859 On 2011-01-12 15:36, Kevin Grittner wrote: > Laszlo Nagy wrote: > >> shared_mem = 6GB >> work_mem = 512MB >> total system memory=24GB > > In addition to the good advice from Ken, I suggest that you set > effective_cache_size (if you haven't already). Add whatever the OS > shows as RAM used for cache to the shared_mem setting. It was 1GB. Now I changed to 2GB. Although the OS shows 9GB inactive memory, we have many concurrent connections to the database server. I hope it is okay to use 2GB. > > But yeah, for your immediate problem, if you can cluster the table > on the index involved, it will be much faster. Of course, if the > table is already in a useful order for some other query, that might > get slower, and unlike some other products, CLUSTER in PostgreSQL > doesn't *maintain* that order for the data as new rows are added -- > so this should probably become a weekly (or monthly or some such) > maintenance operation. Thank you! After clustering, queries are really fast. I don't worry about other queries. This is the only way we use this table - get details for a given id value. I put the CLUSTER command into a cron script that runs daily. For the second time, it took 2 minutes to run so I guess it will be fine. Thank you for your help. Laszlo