On 07 Jul 2015, at 22:52, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: > On Tue, Jul 7, 2015 at 3:33 PM, Graeme B. Bell <graeme.bell@xxxxxxxx> wrote: >> >> Hi Merlin, >> >> Long story short - thanks for the reply, but you're not measuring anything about the parallelism of code running in a pl/pgsql environment here. You're just measuring whether postgres can parallelise entering that environment and get back out. Don't get me wrong - it's great that this scales well because it affects situations where you have lots of calls to trivial functions. >> However it's not the problem I'm talking about. I mean 'real' pl'pgsql functions. e.g. things that you might find in postgis or similar. > > Maybe so. But it will be a lot easier for me (and others on this) > list if you submit a self contained test case that runs via pgbench. Hi Merlin, 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). e.g. did you see these parts of my previous email "To clear up the issue I build a little test harness around your comment below." "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. I haven't used perf with pgbench before, and I can't run any code today. If you're interested in this but short on time, maybe you can glance at the repo above and just add 'perf' at the appropriate point in the rbuild wrapper. Graeme. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
