Re: Increasing default value for effective_io_concurrency?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Increasing default value for effective_io_concurrency?
Date: 2019-07-03 15:04:59
Message-ID: CA+TgmobaEaXQpdj4AtaCgGwkDJ11nCpf=cwudGWeEAaW82fWEw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 1, 2019 at 7:32 PM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2019-07-03 15:20:51 Re: pg_waldump and PREPARE
Previous Message Fabien COELHO 2019-07-03 14:29:23 Re: [PATCH v4] Add \warn to psql