RE: [Patch] Optimize dropping of relation buffers using dlist
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: [Patch] Optimize dropping of relation buffers using dlist |
Дата | |
Msg-id | TYAPR01MB2990C4EFE63F066F83D2A603FEE70@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 |
The patch looks OK. I think as Thomas-san suggested, we can remove the modification to smgrnblocks() and don't care wheterthe size is cached or not. But I think the current patch is good too, so I'd like to leave it up to a committer todecide which to choose. I measured performance in a different angle -- the time DropRelFileNodeBuffers() and DropRelFileNodeAllBuffers() took. Thatreveals the direct improvement and degradation. I used 1,000 tables, each of which is 1 MB. I used shared_buffers = 128 MB for the case where the traditional full bufferscan is done, and shared_buffers = 100 GB for the case where the optimization path takes effect. The results are almost good as follows: A. UNPATCHED 128 MB shared_buffers 1. VACUUM = 0.04 seconds 2. TRUNCATE = 0.04 seconds 100 GB shared_buffers 3. VACUUM = 69.4 seconds 4. TRUNCATE = 69.1 seconds B. PATCHED 128 MB shared_buffers (full scan) 5. VACUUM = 0.04 seconds 6. TRUNCATE = 0.07 seconds 100 GB shared_buffers (optimized path) 7. VACUUM = 0.02 seconds 8. TRUNCATE = 0.08 seconds So, I'd like to mark this as ready for committer. Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: