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?
|
Список | 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 по дате отправления: