Re: [WIP] Performance Improvement by reducing WAL for Update Operation
От | Amit Kapila |
---|---|
Тема | Re: [WIP] Performance Improvement by reducing WAL for Update Operation |
Дата | |
Msg-id | 001801cd81aa$fdca00f0$f95e02d0$@kapila@huawei.com обсуждение исходный текст |
Ответ на | Re: [WIP] Performance Improvement by reducing WAL for Update Operation (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [WIP] Performance Improvement by reducing WAL for
Update Operation
|
Список | pgsql-hackers |
From: Bruce Momjian [mailto:bruce@momjian.us] Sent: Friday, August 24, 2012 2:12 AM On Wed, Aug 22, 2012 at 07:38:33PM +0530, Amit Kapila wrote: >> I had made sure no full_page_write happens by making checkpoint interval and >> checkpoints segments longer. >> > > >> Original code - 1.8G Modified code - 1.1G Diff - 63% reduction, incase of >> fill factor 100. >> Original code - 1.6G Modified code - 1.1G Diff - 45% reduction, incase of >> fill factor 80. > > > >> I am still in process of collecting synchronous commit mode on data. > Wow, that sounds promising. Thanks you. Right now I am collecting the data for Synchronous_commit =on mode; My initial observation is that incase fsync is off, the results are good(around 50% perf improvement). However if fsync is on, the performance results fall down to 3~5%. I am not sure even if the data for I/O is reduced, Still why there is no big performance gain as in case of Synchronous_commit = off or when fsync is off. I am trying with different methods of wal_sync_method parameter and by setting some value of commit_delay as suggested by Peter Geoghegan in one of his mails. Please suggest me if anyone has any thoughts on what kind of parameter's are best for such a use case or let me know if I am missing anything and such kind of performance improvement can only improve performance for fsync =off case. With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: