Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZCw1F-0006JN-OF for pgsql-performance@arkaria.postgresql.org; Wed, 08 Jul 2015 20:32:37 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZCw1E-0005rz-8h for pgsql-performance@arkaria.postgresql.org; Wed, 08 Jul 2015 20:32:36 +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 1ZCvwR-0000PY-Mk for pgsql-performance@postgresql.org; Wed, 08 Jul 2015 20:27:39 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1ZCvwO-0004iZ-8e for pgsql-performance@postgresql.org; Wed, 08 Jul 2015 20:27:38 +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 C7446860002; Wed, 8 Jul 2015 22:27:34 +0200 (CEST) Date: Wed, 8 Jul 2015 22:27:33 +0200 From: Andres Freund To: Merlin Moncure Cc: Craig James , "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: <20150708202733.GS10242@alap3.anarazel.de> References: <6E55113B-FA05-433C-9B21-623F798EE935@skogoglandskap.no> <559CB5BF.2080509@commandprompt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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 use all CPUs up to the > >> max available resource. > >> > >> With PostgreSQL, that isn't going to happen unless you are running (at > >> least) 8 functions across 8 connections. > > > > > > Well, right, which is why I mentioned "even with dozens of clients." > > Shouldn't that scale to at least all of the CPUs in use if the function is > > CPU intensive (which it is)? > > only in the absence of inter-process locking and cache line bouncing. And addititionally memory bandwidth (shared between everything, even in the numa case), cross socket/bus bandwidth (absolutely performance critical in multi-socket configurations), cache capacity (shared between cores, and sometimes even sockets!). -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance