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

On 08 Jul 2015, at 13:20, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2015-07-08 11:13:04 +0000, Graeme B. Bell wrote:
>> I'm guessing you are maybe pressed for time at the moment because I
>> already clearly included this on the last email, as well as the links
>> to the alternative benchmarks with the same problem I referred to on
>> both of my last emails which are also trivial to drop into pgbench
>> (cut/paste).
>
> You realize that you want something here, not Merlin, right?

Hi Andreas,

My email was saying it's not helpful for anyone on the list for him to keep asking me to give him X and me to keep sending it. Do you disagree with that idea?

I tried to phrase my request politely, but perhaps I failed. If you have suggestions for better ways to say "I already sent it, twice" more politely in this situation, I'd welcome them off list.

He asked me to disclose the function body I was testing. I did that, *and* also disclosed the entire approach to the benchmark too in a way that made it trivial for him or others to replicate the situation I'd found. I'm pretty sure you should not be discouraging this kind of thing in bug/performance reports.

I get your point that when you're asking for other people to look at something with you, don't antagonise them.

I didn't intend it as antagonising and Merlin hasn't mailed me anything to say he was antagonised. I'm quite sure he's capable of defending himself or communicating with me himself if he does feel antagonised by something. I hope we can end the discussion of that here?

Merlin, if you were antagonised, sorry, I did not mean to antagonise you. I just wanted to just wanted make it clear that I'd sent you what you asked for, + more, and that I was surprised you hadn't noticed it.

>> "To clear up the issue I build a little test harness around your comment below."
>> "http://github.com/gbb/ppppt"
>
> Well, that requires reviewing the source code of the run script and
> such.

No, of course it doesn't. It appears that you didn't look at the repo or read my previous mail before you wrote this.

I do not wish to antagonise you either, so please go and look at the repo before you write the next reply.

"http://github.com/gbb/ppppt
Just pick any function you like, there are 6 there, and 3 of them demonstrate 2 different problems, all of it is clearly documented."

When you open up the repo, there are the tests
https://github.com/gbb/ppppt/tree/master/tests

You don't need to review any code from the run script. The functions are there as isolated files and what they are intended to demonstrate is clearly described with text and graphics. I could see your point if I had mailed out some giant script with a bunch of SQL calls embedded in its guts, but that's the opposite of what I did here.

Did you find it difficult to navigate the repo structure (2 folders, a few files)? If so please let me know off-list what was difficult and I will see if I can improve it.

> I think we shouldn't discuss this on two threads (-performance, -bugs),
> that makes it hard to follow. Given Tom's more detailed answer I think
> the -bugs thread already contains more pertinent information.

I don't necessarily disagree with this idea, but...

How many people concerned with performance are following the -bugs list? How much space is there for discussion of this on -bugs? Since only working solutions for this performance problem so far are all user-side rather than commiter-side, why would you want to restrict that information to a commiter-side list?

It has developed this way because I noticed it as a performance issue first, then decided to report it as a potential bug.

Perhaps it would be useful to keep the discussion separate as the -commiter side aspects (how to fix this at the server level) and -user side (what you can do to improve performance right now). I will defer to general opinion on this in my follow-up posts.

Graeme.