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

From: James Cloos <cloos(at)jhcloos(dot)com>
To: "Graeme B(dot) Bell" <graeme(dot)bell(at)nibio(dot)no>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Craig James <cjames(at)emolecules(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Date: 2015-07-11 23:18:21
Message-ID: m3pp3y7076.fsf@carbon.jhcloos.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

>>>>> "GBB" == Graeme B Bell <graeme(dot)bell(at)nibio(dot)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(at)jhcloos(dot)com> OpenPGP: 0x997A9F17ED7DAEA6

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ben Hoyt 2015-07-13 20:54:29 Query planner not using indexes with JOIN query and OR clause
Previous Message Jeff Janes 2015-07-10 16:20:21 Re: QUERY PLANNER - Indexe mono column VS composite Index