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

Graeme Bell