(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