Re: Allow a per-tablespace effective_io_concurrency setting

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Allow a per-tablespace effective_io_concurrency setting
Дата
Msg-id CAHyXU0zCXsiOLzF5dkt-Yqm77JYr5x7=933EVyBa6ufuyGqKqw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Allow a per-tablespace effective_io_concurrency setting  (Andres Freund <andres@anarazel.de>)
Ответы Re: Allow a per-tablespace effective_io_concurrency setting  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
On Wed, Sep 2, 2015 at 5:38 PM, Andres Freund <andres@anarazel.de> wrote:
> If you additionally take into account hardware realities where you have
> multiple platters, multiple spindles, command queueing etc, that's even
> more true. A single rotation of a single platter with command queuing
> can often read several non consecutive blocks if they're on a similar

Yeah.  And in the case of solid state disks, it's really a much more
simple case of, "synchronously reading from the disk block by block
does not fully utilize the drive because of various introduced
latencies".  I find this talk of platters and spindles to be somewhat
baroque; for a 200$ part I have to work pretty hard to max out the
drive when reading and I'm still not completely sure if it's the drive
itself, postgres, cpu, or sata interface bottlenecking me.  This will
require a rethink of e_i_o configuration; in the old days there were
physical limitations of the drives that were in the way regardless of
the software stack but we are in a new era, I think.  I'm convinced
prefetching works and we're going to want to aggressively prefetch
anything and everything possible.  SSD controllers (at least the intel
ones) are very smart.

merlin



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: September 2015 Commitfest
Следующее
От: Kouhei Kaigai
Дата:
Сообщение: Re: Foreign join pushdown vs EvalPlanQual