(2013/12/10 22:55), Claudio Freire wrote:
On Tue, Dec 10, 2013 at 5:03 AM, KONDO Mitsumasa
<kondo.mitsum...@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 readahead paraemeter 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
