| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Allow a per-tablespace effective_io_concurrency setting |
| Date: | 2015-09-02 22:10:08 |
| Message-ID: | CAMkU=1ytT-s37DMjx5GZpm1yNgDaXW=Gffe6LU_ZnD1=bWMQyg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On Wed, Sep 2, 2015 at 2:31 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 09/02/2015 02:25 PM, Tomas Vondra wrote:
> >
> > As I explained, spindles have very little to do with it - you need
> > multiple I/O requests per device, to get the benefit. Sure, the DBAs
> > should know how many spindles they have and should be able to determine
> > optimal IO depth. But we actually say this in the docs:
>
> My experience with performance tuning is that values above 3 have no
> real effect on how queries are executed.
>
Perhaps one reason is that the planner assumes it will get no benefit from
this setting, meaning it is somewhat unlikely to choose the types of plans
which would actually show a benefit from higher values.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-09-02 22:13:13 | Re: Memory prefetching while sequentially fetching from SortTuple array, tuplestore |
| Previous Message | Merlin Moncure | 2015-09-02 21:58:33 | Re: Allow a per-tablespace effective_io_concurrency setting |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2015-09-02 22:23:29 | Re: Allow a per-tablespace effective_io_concurrency setting |
| Previous Message | Merlin Moncure | 2015-09-02 21:58:33 | Re: Allow a per-tablespace effective_io_concurrency setting |