Re: Very big insert/join performance problem (bacula) - Mailing list pgsql-performance

From Robert Haas
Subject Re: Very big insert/join performance problem (bacula)
Date
Msg-id 603c8f070907252031x66d07afcmce09cccebbfbfd96@mail.gmail.com
Whole thread Raw
In response to Re: Very big insert/join performance problem (bacula)  (Marc Cousin <cousinmarc@gmail.com>)
List pgsql-performance
On Fri, Jul 24, 2009 at 1:13 AM, Marc Cousin<cousinmarc@gmail.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.)

...Robert

pgsql-performance by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [BUGS] Postgres user authentification or LDAP authentification
Next
From: Greg Caulton
Date:
Subject: Nested loop Query performance on PK