From: | "Eric Comeau" <ecomeau(at)signiant(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Very big insert/join performance problem (bacula) |
Date: | 2009-07-27 10:43:07 |
Message-ID: | h4k0c2$gpa$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>>> 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
How about adding a comment to the wiki performance page....
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-07-27 10:53:06 | Re: Can Postgres use an INDEX over an OR? |
Previous Message | Developer | 2009-07-27 09:06:41 | More speed counting rows |