RE: [Patch] Optimize dropping of relation buffers using dlist

Поиск
Список
Период
Сортировка
От tsunakawa.takay@fujitsu.com
Тема RE: [Patch] Optimize dropping of relation buffers using dlist
Дата
Msg-id TYAPR01MB29908BD15E0C94731B9ED9A0FE300@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  (Amit Kapila <amit.kapila16@gmail.com>)
Re: [Patch] Optimize dropping of relation buffers using dlist  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
From: Jamison, Kirk/ジャミソン カーク <k.jamison@fujitsu.com>
> Recovery performance measurement results below.
> But it seems there are overhead even with large shared buffers.
>
> | s_b   | master | patched | %reg  |
> |-------|--------|---------|-------|
> | 128MB | 36.052 | 39.451  | 8.62% |
> | 1GB   | 21.731 | 21.73   | 0.00% |
> | 20GB  | 24.534 | 25.137  | 2.40% |
> | 100GB | 30.54  | 31.541  | 3.17% |

Did you really check that the optimization path is entered and the traditional path is never entered?

With the following code, when the main fork does not meet the optimization criteria, other forks are not optimized as
well. You want to determine each fork's optimization separately, don't you? 

+        /* If blocks are invalid, exit the optimization and execute full scan */
+        if (nTotalBlocks == InvalidBlockNumber)
+            break;


+        else
+            break;
+    }
     for (i = 0; i < NBuffers; i++)


Regards
Takayuki Tsunakawa






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: New statistics for tuning WAL buffer size
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [Patch] Optimize dropping of relation buffers using dlist