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

Поиск
Список
Период
Сортировка
От Graeme B. Bell
Тема Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Дата
Msg-id C3FA264F-B1DB-44CF-B466-8714862BFF4B@skogoglandskap.no
обсуждение исходный текст
Ответ на Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?  (Andres Freund <andres@anarazel.de>)
Список pgsql-performance
On 08 Jul 2015, at 13:20, Andres Freund <andres@anarazel.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
sendingit.  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
sentit, 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
benchmarktoo in a way that made it trivial for him or others to replicate the situation I'd found. I'm pretty sure you
shouldnot 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
capableof defending himself or communicating with me himself if he does feel antagonised by something. I hope we can
endthe 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
thatI'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
clearlydocumented." 

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
intendedto demonstrate is clearly described with text and graphics. I could see your point if I had mailed out some
giantscript 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
whatwas 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,
whywould 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-upposts.  

Graeme.

В списке pgsql-performance по дате отправления:

Предыдущее
От: "Graeme B. Bell"
Дата:
Сообщение: Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Hmmm... why does pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?