Skip site navigation (1) Skip section navigation (2)

Re: Very big insert/join performance problem (bacula)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Marc Cousin <cousinmarc(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Very big insert/join performance problem (bacula)
Date: 2009-07-26 03:31:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Fri, Jul 24, 2009 at 1:13 AM, Marc Cousin<cousinmarc(at)gmail(dot)com> wrote:
>> It really has very little impact.  It only affects index scans, and
>> even then only if effective_cache_size is less than the size of the
>> table.
>> Essentially, when this kicks in, it models the effect that if you are
>> index scanning a table much larger than the size of your cache, you
>> might have to reread some blocks that you previously read in during
>> *that same index scan*.
> Ok, thanks for clearing that up for me. Still, I think the doc could be
> improved on this point (sorry to be a bit obsessed with that, but I'm one of
> the french translators, so I like the doc to be perfect :) )

Yes, I agree.  I was confused for quite a long time, too, until I read
the code.  I think many people think this value is much more important
than it really is.

(That having been said, I have no current plans to write such a doc
patch myself.)


In response to


pgsql-performance by date

Next:From: Greg CaultonDate: 2009-07-26 05:02:42
Subject: Nested loop Query performance on PK
Previous:From: Magnus HaganderDate: 2009-07-24 07:17:38
Subject: Re: Postgres user authentification or LDAP authentification

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group