Re: Optimize kernel readahead using buffer access strategy

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.

In response to

Responses

Browse pgsql-hackers by date

  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