Re: Optimize kernel readahead using buffer access strategy
От | KONDO Mitsumasa |
---|---|
Тема | Re: Optimize kernel readahead using buffer access strategy |
Дата | |
Msg-id | 52A802B0.2030109@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Optimize kernel readahead using buffer access strategy (Claudio Freire <klaussfreire@gmail.com>) |
Ответы |
Re: Optimize kernel readahead using buffer access strategy
|
Список | pgsql-hackers |
(2013/12/10 22:55), Claudio Freire wrote: > On Tue, Dec 10, 2013 at 5:03 AM, KONDO Mitsumasa > <kondo.mitsumasa@lab.ntt.co.jp> wrote: >> I revise this patch and re-run performance test, it can work collectry in >> Linux and no complile wanings. I add GUC about enable_kernel_readahead >> option in new version. When this GUC is on(default), it works in >> POSIX_FADV_NORMAL which is general readahead in OS. And when it is off, it >> works in POSXI_FADV_RANDOM or POSIX_FADV_SEQUENTIAL which is judged by >> buffer hint in Postgres, readahead parameter is optimized by postgres. We >> can change this parameter in their transactions everywhere and everytime. > > I'd change the naming to OK. I think "on" or "off" naming is not good, too. > enable_readahead=os|fadvise > > with os = on, fadvise = off Hmm. fadvise is method and is not a purpose. So I consider another idea of this GUC. 1)readahead_strategy=os|pg This naming is good for future another implements. If we will want to set maximum readaheadparaemeter which is always use POSIX_FADV_SEQUENTIAL, we can set "max". 2)readahead_optimizer=os|pg or readahaed_strategist=os|pg This naming is easy to understand to who is opitimized readahead. But it isn't extensibility for future another implements. > And, if you want to keep the on/off values, I'd reverse them. Because > off reads more like "I don't do anything special", and in your patch > it's quite the opposite. I understand your feeling. If we adopt "on|off" setting, I would like to set GUC optimized_readahead=off|on. Regards, -- Mitsumasa KONDO NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: