Re: Filesystem Direct I/O and WAL sync option
От | Gregory Stark |
---|---|
Тема | Re: Filesystem Direct I/O and WAL sync option |
Дата | |
Msg-id | 87wsxgcus2.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Filesystem Direct I/O and WAL sync option (Dimitri <dimitrik.fr@gmail.com>) |
Ответы |
Re: Filesystem Direct I/O and WAL sync option
|
Список | pgsql-performance |
"Dimitri" <dimitrik.fr@gmail.com> writes: > Yes Gregory, that's why I'm asking, because from 1800 transactions/sec > I'm jumping to 2800 transactions/sec! and it's more than important > performance level increase :)) wow. That's kind of suspicious though. Does the new configuration take advantage of the lack of the filesystem cache by increasing the size of shared_buffers? Even then I wouldn't expect such a big boost unless you got very lucky with the size of your working set compared to the two sizes of shared_buffers. It seems likely that somehow this change is not providing the same guarantees as fsync. Perhaps fsync is actually implementing IDE write barriers and the sync mode is just flushing buffers to the hard drive cache and then returning. What transaction rate do you get if you just have a single connection streaming inserts in autocommit mode? What kind of transaction rate do you get with both sync mode on and fsync=on in Postgres? And did you say this with a battery backed cache? In theory fsync=on/off and shouldn't make much difference at all with a battery backed cache. Stranger and stranger. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-performance по дате отправления: