Re: WAL Performance Improvements
От | Helge Bahmann |
---|---|
Тема | Re: WAL Performance Improvements |
Дата | |
Msg-id | Pine.LNX.4.21.0202261350400.10860-100000@lothlorien.stunet2.tu-freiberg.de обсуждение исходный текст |
Ответ на | Re: WAL Performance Improvements (Janardhana Reddy <jana-reddy@mediaring.com.sg>) |
Ответы |
Re: WAL Performance Improvements
|
Список | pgsql-patches |
On Tue, 26 Feb 2002, Janardhana Reddy wrote: > SUMMARY : > > Test1: (data_size= 8192 , with test program) > fdatasync time +write time: 3141+46 = 3187 usec/call > Time taken for 10000 iterations: nearly 40 seconds > Test2 : (data_size = 160, with test program) > fdatasync time+write time: 396 +13 = 409 usec/call > Time taken for 10000 iterations: nealy 4 seconds This only shows that your harddisk is doing write caching, although it claims it does not (And on such systems I am tempted to say you can turn off fsync unconditionally as it will gain you almost nothing). Please look at the numbers: It is really *impossible* for any harddisk to write to the same location more than 2000 times per second - simply due to the fact that the disks are not rotating that fast. The fact that turning writing caching on or off does not make a difference should make you suspicious. (In fact looking more closely at the numbers I am tempted to bet that you operate your IDE disk in PIO mode: 1024bytes/400usec= 8192bytes/3200usec= 2.5MByte/s, and all you are benchmarking is the PIO transfer rate of your IDE-controller/CPU combination). This is not to say that your WAL optimization is worthless, but the benchmark you gave is certainly wrong. Regards -- Helge Bahmann <bahmann@math.tu-freiberg.de> /| \__ Network admin, systems programmer /_|____\ _/\ | __) $ ./configure \\ \|__/__| checking whether build environment is sane... yes \\/___/ | checking for AIX... no (we already did this) |
В списке pgsql-patches по дате отправления: