Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 107ADB5DC33 for ; Tue, 28 Jun 2011 21:11:12 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 59181-03-5 for ; Wed, 29 Jun 2011 00:11:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.gransy.com (mail.gransy.com [82.208.29.194]) by mail.postgresql.org (Postfix) with ESMTP id E3467B5DC06 for ; Tue, 28 Jun 2011 21:10:55 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by mail.gransy.com (Postfix) with ESMTP id 824CD4A2205 for ; Wed, 29 Jun 2011 02:10:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at nathalia.gransy.com Received: from mail.gransy.com ([127.0.0.1]) by localhost (Nathalka.gransy.com.gransy.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYnKaD30tXYS for ; Wed, 29 Jun 2011 02:10:47 +0200 (CEST) Received: from [192.168.1.221] (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 8BD0B4A21EC for ; Wed, 29 Jun 2011 02:10:47 +0200 (CEST) Message-ID: <4E0A6D88.8010407@fuzzy.cz> Date: Wed, 29 Jun 2011 02:10:48 +0200 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110619 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Slow performance when querying millions of rows References: <20110628235050.77a9baf7@mail.openroadsconsulting.com> In-Reply-To: <20110628235050.77a9baf7@mail.openroadsconsulting.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.585 tagged_above=-10 required=5 tests=BAYES_00=-1.9, SARE_MILLIONSOF=0.315 X-Spam-Level: X-Archive-Number: 201106/265 X-Sequence-Number: 44198 Dne 29.6.2011 01:50, Craig McIlwee napsal(a): >> > work_mem: 512MB >> > shared_buffers: 64MB, 512MB, and 1024MB, each yielded the same query >> > plan and took the same amount of time to execute give or take a few >> > seconds >> >> shared_buffers doesn't normally impact the query plan; it impacts how >> much churn there is between the database and the operating system cache, >> mainly important for making write-heavy work efficient. On Windows, >> you'll probably be safe to set this to 512MB and forget about it. It >> doesn't benefit from large values anyway. > > I was thinking that shared buffers controlled the amount of data, > primarily table and index pages, that the database could store in memory > at once. Based on that assumption, I thought that a larger value would > enable an entire table + index to be in memory together and speed up the > query. Am I wrong? Well, you're right and wrong at the same time. The shared buffers really controls the amount of data that may be read into the database cache, that's true. But this value is not used when building the execution plan. There's another value (effective_cache_size) that is used when planning a query. >> > Ive read documentation that says I should be able to set statistics >> > values for an entire table as opposed to per column, but havent found >> > how to do that. I guess I was either too lazy to update statistics on >> > each column or just didnt think it would help much. Link to the docs? According to http://www.postgresql.org/docs/current/static/sql-altertable.html it's possible to set this only at the column level. And of course there's a GUC default_statistics_target that defines default value. Tomas