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

From James Cloos
Subject Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Date
Msg-id m3pp3y7076.fsf@carbon.jhcloos.org
Whole thread Raw
In response to 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>)
List 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 by date:

Previous
From: Jeff Janes
Date:
Subject: Re: QUERY PLANNER - Indexe mono column VS composite Index
Next
From: Ben Hoyt
Date:
Subject: Query planner not using indexes with JOIN query and OR clause