From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)heroku(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Subject: | Re: Optimize kernel readahead using buffer access strategy |
Date: | 2013-12-10 13:55:58 |
Message-ID: | CAGTBQpb5CfqkTCPxQ34ZmMEEQq4hxDWCaXP59+t8AD=GOt85GQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 10, 2013 at 5:03 AM, KONDO Mitsumasa
<kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)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
enable_readahead=os|fadvise
with os = on, fadvise = off
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2013-12-10 14:02:35 | Re: ANALYZE sampling is too good |
Previous Message | Serge Negodyuck | 2013-12-10 13:22:49 | Re: BUG #8673: Could not open file "pg_multixact/members/xxxx" on slave during hot_standby |