Re: [PERFORM] Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

2015-07-08 Thread Tom Lane
and...@anarazel.de (Andres Freund) writes: > On 2015-07-08 15:38:24 -0700, Craig James wrote: >> From my admittedly naive point of view, it's hard to see why any of this >> matters. I have functions that do purely CPU-intensive mathematical >> calculations ... you could imagine something like is_pr

Re: [PERFORM] Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

2015-07-08 Thread Andres Freund
On 2015-07-08 15:38:24 -0700, Craig James wrote: > From my admittedly naive point of view, it's hard to see why any of this > matters. I have functions that do purely CPU-intensive mathematical > calculations ... you could imagine something like is_prime(N) that > determines if N is a prime number.

Re: [PERFORM] Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

2015-07-08 Thread Craig James
On Wed, Jul 8, 2015 at 1:27 PM, Andres Freund wrote: > On 2015-07-08 13:46:53 -0500, Merlin Moncure wrote: > > On Wed, Jul 8, 2015 at 12:48 PM, Craig James > wrote: > > > On Tue, Jul 7, 2015 at 10:31 PM, Joshua D. Drake > > > >> Using Apache Fast-CGI, you are going to fork a process for each >

Re: [PERFORM] Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

2015-07-08 Thread Andres Freund
On 2015-07-08 13:46:53 -0500, Merlin Moncure wrote: > On Wed, Jul 8, 2015 at 12:48 PM, Craig James wrote: > > On Tue, Jul 7, 2015 at 10:31 PM, Joshua D. Drake > >> Using Apache Fast-CGI, you are going to fork a process for each instance > >> of the function being executed and that in turn will us

Re: [PERFORM] Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

2015-07-08 Thread Merlin Moncure
On Wed, Jul 8, 2015 at 12:48 PM, Craig James wrote: > On Tue, Jul 7, 2015 at 10:31 PM, Joshua D. Drake > wrote: >> >> >> On 07/07/2015 08:05 PM, Craig James wrote: >>> >>> >>> >>> No ideas, but I ran into the same thing. I have a set of C/C++ functions >>> that put some chemistry calculations int

Re: [PERFORM] Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

2015-07-08 Thread Craig James
On Wed, Jul 8, 2015 at 10:52 AM, Joshua D. Drake wrote: > > On 07/08/2015 10:48 AM, Craig James wrote: > > I admit that I haven't read this whole thread but: >> >> Using Apache Fast-CGI, you are going to fork a process for each >> instance of the function being executed and that in t

Re: [PERFORM] Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

2015-07-08 Thread Joshua D. Drake
On 07/08/2015 10:48 AM, Craig James wrote: I admit that I haven't read this whole thread but: Using Apache Fast-CGI, you are going to fork a process for each instance of the function being executed and that in turn will use all CPUs up to the max available resource. With P

Re: [PERFORM] Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

2015-07-08 Thread Craig James
On Tue, Jul 7, 2015 at 10:31 PM, Joshua D. Drake wrote: > > On 07/07/2015 08:05 PM, Craig James wrote: > >> >> >> No ideas, but I ran into the same thing. I have a set of C/C++ functions >> that put some chemistry calculations into Postgres as extensions (things >> like, "calculate the molecular

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

2015-07-08 Thread Andres Freund
On 2015-07-08 11:13:04 +, 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

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

2015-07-08 Thread Graeme B. Bell
On 07 Jul 2015, at 22:52, Merlin Moncure wrote: > On Tue, Jul 7, 2015 at 3:33 PM, Graeme B. Bell 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 me

Re: [PERFORM] Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this?

2015-07-08 Thread Graeme B. Bell
> On 07/07/2015 08:05 PM, Craig James wrote: >> >> >> No ideas, but I ran into the same thing. I have a set of C/C++ functions >> that put some chemistry calculations into Postgres as extensions (things >> like, "calculate the molecular weight of this molecule"). As SQL >> functions, the whole th

Re: [PERFORM] wildcard text filter switched to boolean column, performance is way worse

2015-07-08 Thread Marc Mamin
Hello, > > > > > > From: pgsql-performance-ow...@postgresql.org > [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Mike Broers > Sent: Dienstag, 7. Juli 2015 18:28 > To: Tom Lane > Cc: pgsql-performance@postgresql.org > Subject: Re: [PERFORM] wildcard text filter switched to boole