RE: [Patch] Optimize dropping of relation buffers using dlist
| От | tsunakawa.takay@fujitsu.com |
|---|---|
| Тема | RE: [Patch] Optimize dropping of relation buffers using dlist |
| Дата | |
| Msg-id | TYAPR01MB2990EA82B62142B7C29DDDE3FE320@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | RE: [Patch] Optimize dropping of relation buffers using dlist ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>) |
| Ответы |
Re: [Patch] Optimize dropping of relation buffers using dlist
|
| Список | pgsql-hackers |
From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com> > I also did not remove the duplicate code from smgrnblocks because Amit-san > mentioned that when the caching for non-recovery cases is implemented, we > can use it for non-recovery cases as well. But the extra code is not used now. The code for future usage should be added when it becomes necessary. Duplicate codemay make people think that you should add an argument to smgrnblocks() instead of adding a new function. + if (reln->smgr_cached_nblocks[forknum] != InvalidBlockNumber) + return reln->smgr_cached_nblocks[forknum]; + else + return InvalidBlockNumber; Anyway, the else block is redundant, as the variable contains InvalidBlockNumber. Also, as Amit-san mentioned, the cause of the slight performance regression when shared_buffers is small needs to be investigatedand addressed. I think you can do it after sharing the performance result with a large shared_buffers. I found no other problem. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: