>> >> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
