Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

Поиск
Список
Период
Сортировка
От James Cloos
Тема Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Дата
Msg-id m3pp3y7076.fsf@carbon.jhcloos.org
обсуждение исходный текст
Ответ на Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?  ("Graeme B. Bell" <graeme.bell@nibio.no>)
Список pgsql-performance
>>>>> "GBB" == Graeme B Bell <graeme.bell@nibio.no> writes:

GBB> 1a. For example AMD CPUs list the number of integer cores (e.g. 16),
GBB> but there is actually only half as many cores available for floating
GBB> point work (8). So if your functions need to use floating point, your
GBB> scaling will suffer badly on FP functions.

That is half as many 256-bit float units; for scalar math and for
128-bit vector math each core gets a half of the float unit.

Only for the 256-bit vector math do the schedulars have to compete for
float unit access.

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: QUERY PLANNER - Indexe mono column VS composite Index
Следующее
От: Ben Hoyt
Дата:
Сообщение: Query planner not using indexes with JOIN query and OR clause