Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZCy5k-0002kJ-GU for pgsql-performance@arkaria.postgresql.org; Wed, 08 Jul 2015 22:45:24 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZCy5j-00074y-Li for pgsql-performance@arkaria.postgresql.org; Wed, 08 Jul 2015 22:45:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZCy5i-00073J-Cw for pgsql-performance@postgresql.org; Wed, 08 Jul 2015 22:45:22 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1ZCy5f-0007Pg-TH for pgsql-performance@postgresql.org; Wed, 08 Jul 2015 22:45:21 +0000 Received: from intern.anarazel.de (p5DDC71B7.dip0.t-ipconnect.de [93.220.113.183]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id 22D52860002; Thu, 9 Jul 2015 00:45:18 +0200 (CEST) Date: Thu, 9 Jul 2015 00:45:18 +0200 To: Craig James Cc: Merlin Moncure , "Joshua D. Drake" , "Graeme B. Bell" , postgres performance list Subject: Re: Hmmm... why does CPU-intensive pl/pgsql code parallelise so badly when queries parallelise fine? Anyone else seen this? Message-ID: <20150708224518.GT10242@alap3.anarazel.de> References: <6E55113B-FA05-433C-9B21-623F798EE935@skogoglandskap.no> <559CB5BF.2080509@commandprompt.com> <20150708202733.GS10242@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [1;5BFrom: Andres Freund From: andres@anarazel.de (Andres Freund) X-Pg-Spam-Score: -4.9 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org 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. I have eight clients that connect to > eight backends. Each client issues an SQL command like, "select > is_prime(N)" where N is a simple number. I mostly replied to Merlin's general point (additionally in the context of plpgsql). But I have a hard time seing that postgres would be the bottleneck for a is_prime() function (or something with similar characteristics) that's written in C where the average runtime is more than, say, a couple thousand cyles. I'd like to see a profile of that. Andres -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance