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

On Thu, Jul 9, 2015 at 10:12 AM, Graeme B. Bell <graeme(dot)bell(at)nibio(dot)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 little bit 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/pgsql functions I doubt my efforts would be that great. I also have other OSS project contributions that need some attention first.
>
> Re: the google effect. Are these mailing list archives mirrored anywhere, incidentally? For example, I notice we just lost http: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