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
Re: [Patch] Optimize dropping of relation buffers using dlist |
Список | 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 по дате отправления: