Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
Дата
Msg-id 603c8f070903131937t1c33fa97k29e7d8d07fa2e83@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
Список pgsql-performance
On Fri, Mar 13, 2009 at 10:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Gregory Stark <stark@enterprisedb.com> writes:
>> Tom Lane <tgl@sss.pgh.pa.us> writes:
>>> Ugh.  So apparently, we actually need to special-case Solaris to not
>>> believe that posix_fadvise works, or we'll waste cycles uselessly
>>> calling a do-nothing function.  Thanks, Sun.
>
>> Do we? Or do we just document that setting effective_cache_size on Solaris
>> won't help?
>
> I assume you meant effective_io_concurrency.  We'd still need a special
> case because the default is currently hard-wired at 1, not 0, if
> configure thinks the function exists.  Also there's a posix_fadvise call
> in xlog.c that that parameter doesn't control anyhow.

I think 1 should mean no prefetching, rather than 0.  If the number of
concurrent I/O requests was 0, that would mean you couldn't perform
any I/O at all.

...Robert

В списке pgsql-performance по дате отправления:

Предыдущее
От: Vamsidhar Thummala
Дата:
Сообщение: Re: Hash Join performance
Следующее
От: Gregory Stark
Дата:
Сообщение: Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4