Re: AIX slow buffer reads

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: AIX slow buffer reads
Дата
Msg-id 4CC87C69.5070301@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: AIX slow buffer reads  (André Volpato <andre.volpato@ecomtecnologia.com.br>)
Ответы Re: AIX slow buffer reads  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: AIX slow buffer reads  (André Volpato <andre.volpato@ecomtecnologia.com.br>)
Re: AIX slow buffer reads  (André Volpato <andre.volpato@ecomtecnologia.com.br>)
Список pgsql-performance
André Volpato wrote:
> |
> | If it is being spent in the bitmap index scan, try setting
> | effective_io_concurrency to 0 for Linux, and see what effect that has.
>
> I disabled effective_io_concurrency at AIX but it made no changes on bitmap index times.
>

Brad's point is that it probably doesn't do anything at all on AIX, and
is already disabled accordingly.  But on Linux, it is doing something,
and that might be contributing to why it's executing so much better on
that platform.  If you disable that parameter on your Debian box, that
should give you an idea whether that particular speed-up is a major
component to the difference you're seeing or not.

Also, if the system check was done by the "vendor team" team, don't
trust them at all.  It doesn't sound like a disk problem is involved in
your case yet, but be sure to do your own basic disk benchmarking too
rather than believing what you're sold.  There's a quick intro to that
at http://www.westnet.com/~gsmith/content/postgresql/pg-disktesting.htm
and a much longer treatment of the subject in my book if you want a lot
more details.  I don't have any AIX-specific tuning advice in there though.

--
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services and Support        www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books


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

Предыдущее
От: Scott Carey
Дата:
Сообщение: Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
Следующее
От: Jon Nelson
Дата:
Сообщение: Re: temporary tables, indexes, and query plans