On Wed, Aug 15, 2012 at 5:19 PM, Bosco Rama wrote:
> On 08/15/12 14:05, Josh Berkus wrote:
>>
>>> That actually makes sense to me. Cluster the rows covered by that
>>> index, let the rest fall where they may. I'm typically only accessing
>>> the rows covered by that index, so I'd get the benefit o
On Tue, Aug 14, 2012 at 1:29 PM, k...@rice.edu wrote:
>
> It probably has to do with the fact that a conditional index, does
> not include every possible row in the table. Although, a "cluster" of
> the matching rows and then leave the rest in place, should work. How
> is that for hand-waving. :)
According to the docs on cluster:
if you tend to access some data more than others, and there is an
index that groups them together, you will benefit from using CLUSTER
however, this doesn't address the situation where you have a
conditional index. For example, we have certain large tables that ha
When reviewing the vacuum logs, I notice that on any given day
autovacuum only seems to touch four of the tables in one of our
schemas (not counting toast tables). However, if I look at the
pgstatspack output for the same day, I see that there are plenty of
other tables receiving a high number of i
I understand that checkpointing is a necessary part of a pgsql
database, but I am also under the impression that you want to find a
balance between how frequently you checkpoint and how much a given
checkpoint has to do. It's all about balancing the disk I/O out to get
a consistent throughput and f
Just wondering is the issue referenced in
http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
is still present in 8.4 or if some tunable (or other) made the use of
hyperthreading a non-issue. We're looking to upgrade our servers soon
for performance reasons and am trying to determ
