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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [Patch] Optimize dropping of relation buffers using dlist
Следующее
От: David Rowley
Дата:
Сообщение: Re: Planner making bad choice in alternative subplan decision