Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?
Дата
Msg-id BANLkTiknULNUt=6kWB7_C0XnkiWugHu96w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?  (Hsien-Wen Chu <chu.hsien.wen@gmail.com>)
Ответы Re: VX_CONCURRENT flag on vxfs( 5.1 or later) for performance for postgresql?  (Dimitri <dimitrik.fr@gmail.com>)
Список pgsql-performance
On Sat, Apr 30, 2011 at 4:51 AM, Hsien-Wen Chu <chu.hsien.wen@gmail.com> wrote:
> since the block size is 8k for the default, and it consisted with many
> tuple/line; as my understand, if any tuple/line is changed(maybe
> update, insert, delete). the block will be marked as dirty block. and
> then it will be flashed to disk by bgwriter.

True...

> so my question is if the data block(8k) is aligned with the file
> system block?  if it is aligned with file system block, so what's the
> potential issue make it is not safe for direct io. (please  assume
> vxfs, vxvm and the disk sector is aligned ).please correct me if any
> incorrect.

It's not about safety - it's about performance.  On a machine with
64GB of RAM, a typical setting for shared_buffers set to 8GB.  If you
start reading blocks into the PostgreSQL cache - or writing them out
of the cache - in a way that bypasses the filesystem cache, you're
going to have only 8GB of cache, instead of some much larger amount.
More cache = better performance.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: Brian Connolly
Дата:
Сообщение: Poor query plan chosen in 9.0.3 vs 8.3.7
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: ask the database engine tuning on the server