On 07 Jul 2015, at 22:52, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Jul 7, 2015 at 3:33 PM, Graeme B. Bell <graeme.bell@nibio.no> wrote:
>>
>> Hi Merlin,
>>
>> Long story short - thanks for the reply, but you're not measuring anything about the parallelism of code running in
apl/pgsql environment here. You're just measuring whether postgres can parallelise entering that environment and get
backout. Don't get me wrong - it's great that this scales well because it affects situations where you have lots of
callsto 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
postgisor 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
wellas the links to the alternative benchmarks with the same problem I referred to on both of my last emails which are
alsotrivial 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
clearlydocumented.
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
appropriatepoint in the rbuild wrapper.
Graeme.