Re: Increasing default value for effective_io_concurrency? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Increasing default value for effective_io_concurrency?
Date
Msg-id CA+TgmobaEaXQpdj4AtaCgGwkDJ11nCpf=cwudGWeEAaW82fWEw@mail.gmail.com
Whole thread Raw
In response to Re: Increasing default value for effective_io_concurrency?  (Andres Freund <andres@anarazel.de>)
Responses Re: Increasing default value for effective_io_concurrency?  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Mon, Jul 1, 2019 at 7:32 PM Andres Freund <andres@anarazel.de> wrote:
> On 2019-06-29 22:15:19 +0200, Tomas Vondra wrote:
> > I think we should consider changing the effective_io_concurrency default
> > value, i.e. the guc that determines how many pages we try to prefetch in
> > a couple of places (the most important being Bitmap Heap Scan).
>
> Maybe we need improve the way it's used / implemented instead - it seems
> just too hard to determine the correct setting as currently implemented.

Perhaps the translation from effective_io_concurrency to a prefetch
distance, which is found in the slightly-misnamed ComputeIoConcurrency
function, should be changed.  The comments therein say:

         * Experimental results show that both of these formulas
aren't aggressive
         * enough, but we don't really have any better proposals.

Perhaps we could test experimentally what works well with N spindles
and then fit a formula to that curve and stick it in here, so that our
tuning is based on practice rather than theory.

I'm not sure if that approach is adequate or not.  It just seems like
something to try.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [PATCH v4] Add \warn to psql
Next
From: Fujii Masao
Date:
Subject: Re: pg_waldump and PREPARE