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

Предыдущее
От: "k.jamison@fujitsu.com"
Дата:
Сообщение: RE: [Patch] Optimize dropping of relation buffers using dlist
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Background writer and checkpointer in crash recovery