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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Very big insert/join performance problem (bacula)
Дата
Msg-id 603c8f070907252031x66d07afcmce09cccebbfbfd96@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Very big insert/join performance problem (bacula)  (Marc Cousin <cousinmarc@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: [BUGS] Postgres user authentification or LDAP authentification
Следующее
От: Greg Caulton
Дата:
Сообщение: Nested loop Query performance on PK