Re: Is this a problem in GenericXLogFinish()?
От | Alexander Lakhin |
---|---|
Тема | Re: Is this a problem in GenericXLogFinish()? |
Дата | |
Msg-id | 9aa385d8-fe75-c35b-cf91-31bb3647d977@gmail.com обсуждение исходный текст |
Ответ на | RE: Is this a problem in GenericXLogFinish()? ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
Re: Is this a problem in GenericXLogFinish()?
|
Список | pgsql-hackers |
Hello Kuroda-san, 30.11.2023 10:28, Hayato Kuroda (Fujitsu) wrote: > Again, good catch. Here is my analysis and fix patch. > I think it is sufficient to add an initialization for writebuf. I agree with the change. It aligns hash_xlog_squeeze_page() with hash_xlog_move_page_contents() in regard to initialization of writebuf. Interestingly enough, the discrepancy exists since these functions appeared with c11453ce0, and I can't see what justified adding the initialization inside hash_xlog_move_page_contents() only. So I think that if this doesn't affect performance, having aligned coding (writebuf initialized in both functions) is better. > I want to add a test case for it as well. I've tested on my env and found that proposed > tuples seems sufficient. > (We must fill the primary bucket, so initial 500 is needed. Also, we must add > many dead pages to lead squeeze operation. Final page seems OK to smaller value.) > > I compared the execution time before/after patching, and they are not so different > (1077 ms -> 1125 ms). > > How do you think? I can confirm that the test case proposed demonstrates what is expected and the duration increase is tolerable, as to me. Best regards, Alexander
В списке pgsql-hackers по дате отправления: