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 Merlin Moncure
Subject Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Date
Msg-id CAHyXU0wEniuEkF39g2qLEYo17zLh6gVjEaFqRfUL4YHEZ=0-KA@mail.gmail.com
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>)
Responses 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
On Thu, Jul 9, 2015 at 10:12 AM, Graeme B. Bell <graeme.bell@nibio.no> wrote:
>>>
>>> 3. I don't disagree that the benchmark code is objectively 'bad' in the sense that it is missing an important
optimisation.
>>
>> Particularly with regards documentation, a patch improving things is
>> much more likely to improve the situation than griping.  Also,
>> conversation on this list gets recorded for posterity and google is
>> remarkably good at matching people looking for problems with
>> solutions.  So, even in absence of a patch perhaps we've made the
>> lives of future head-scratchers a little bit easier with this
>> discussion.
>
> I agree that patch>gripe, and about the google aspect. But nonetheless, a well-intentioned gripe is > ignorance of a
problem.
>
> As mentioned earlier, I'm sick just now and will be back in hospital again tomorrow & monday, so a patch may be a
littlebit much to ask from me here :-) It's a bit much even keeping up with the posts on the thread so far. 
>
> I might try to fix the documentation a bit later, though as someone with no experience in marking up volatility on
pl/pgsqlfunctions I doubt my efforts would be that great. I also have other OSS project contributions that need some
attentionfirst. 
>
> Re: the google effect. Are these mailing list archives mirrored anywhere, incidentally? For example, I notice we just
losthttp:reddit.com/r/amd at the weekend, all the discussion of the last few years on that forum is out of reach. 

The community maintains it's own mailing list archives in
postgresql.org.  Short of an array of tactical nuclear strikes this is
going to be preserved because it represents the history of the project
and in many ways is as important as the source code itself.

The archives are also mirrored by a number of high quality providers
such as nabble (which tend to beat our archives in google rankings --
likely due to the improved interface).

merlin


pgsql-performance by date:

Previous
From: "Graeme B. Bell"
Date:
Subject: Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Next
From: "Graeme B. Bell"
Date:
Subject: Re: [BUGS] BUG #13493: pl/pgsql doesn't scale with cpus (PG9.3, 9.4)