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

>>
>> 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.   

Graeme Bell