Re: _mdfd_getseg can be expensive

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: _mdfd_getseg can be expensive
Дата
Msg-id CAM3SWZR3ScU+NhNnL-sEsyDadV0DfyoyKS+Wu0rBdbq2E2M3_g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: _mdfd_getseg can be expensive  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Thu, Jun 30, 2016 at 7:08 PM, Andres Freund <andres@anarazel.de> wrote:
> If you have a big enough index (maybe ~150GB+), sure. Before that,
> probably not.
>
> It's usually pretty easy to see in cpu profiles whether this issue
> exists.

I think that this is a contributing factor to why merging in parallel
CREATE INDEX becomes much more CPU bound when building such very large
indexes, which Corey Huinker has benchmarked using an advanced copy of
the patch. He has shown cases that are sped up by 3.6x when 8 parallel
workers are used (compared to a serial CREATE INDEX), but a several
hundred gigabyte index case only sees a speedup of about 1.5x. (This
bottleneck affects serial CREATE INDEX merging just as much as
parallel, since that part isn't parallelized, but it's far more
noticeable with parallel CREATE INDEX simply because merging in the
leader becomes a huge bottleneck).

Those two cases were not exactly comparable in perhaps several other
ways, but even still my sense is that that this can be at least
partially explained by md.c bottlenecks. This is something that we'll
need to confirm through profiling. Hopefully it's just this one
bottleneck.

--
Peter Geoghegan



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

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Reviewing freeze map code
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [sqlsmith] ERROR: plan should not reference subplan's variable