Re: data on devel code perf dip
От | Alvaro Herrera |
---|---|
Тема | Re: data on devel code perf dip |
Дата | |
Msg-id | 20050812013112.GA9504@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: data on devel code perf dip (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: data on devel code perf dip
|
Список | pgsql-hackers |
On Thu, Aug 11, 2005 at 09:02:03PM -0400, Tom Lane wrote: > I am sure I will get some pushback if I propose reverting the O_DIRECT > patch, so could you try to get some more-specific evidence? Like pull > the CVS tree from just before and just after this patch and compare > performance? Quoth the open(2) manpage: O_DIRECT Try to minimize cache effects of the I/O to and from this file. In general thiswill degrade performance, but it is useful in special situations, such as when applications do their own caching. File I/O is done directly to/from user space buffers. The I/O is synchronous, i.e.,at the comple- tion of the read(2) or write(2) system call, data is guaran- teed to have beentransferred. In light of this, may I ask whether it makes sense to compare the performance of two runs with similar shared_buffer settings? With O_DIRECT, I understand from this manpage that the OS is going to do little or no page caching, so shared_buffers should be increased to account for this fact. Am I missing something? -- Alvaro Herrera (<alvherre[a]alvh.no-ip.org>) "Hay que recordar que la existencia en el cosmos, y particularmente la elaboración de civilizaciones dentre de él no son, por desgracia, nada idílicas" (Ijon Tichy)
В списке pgsql-hackers по дате отправления: