Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1guOAZ-00018T-6I for pgsql-performance@arkaria.postgresql.org; Thu, 14 Feb 2019 21:03:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1guOAX-0003Tb-Sm for pgsql-performance@arkaria.postgresql.org; Thu, 14 Feb 2019 21:03:41 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1guOAX-0003TU-Gc for pgsql-performance@lists.postgresql.org; Thu, 14 Feb 2019 21:03:41 +0000 Received: from mail-it1-x141.google.com ([2607:f8b0:4864:20::141]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1guOAU-0000Gz-8x for pgsql-performance@lists.postgresql.org; Thu, 14 Feb 2019 21:03:41 +0000 Received: by mail-it1-x141.google.com with SMTP id z131so8358495itf.5 for ; Thu, 14 Feb 2019 13:03:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to:user-agent; bh=o9OK/KSdIv9E/B1ffRtWt+ObJcCTTGZ0MP5YkggrOVI=; b=cljThwdPa3xapF3Xd+ZGQD6XRmudJm6IJr228OwsjVnx8uE6XMe85Po8JoNmpfxfTI nbxJZ7ZE37b1exW+ZLmjYNNhQPMo4yRz9h6f2kwc9JGKjCkwFauqblz03QdetPw7iHak hzkvP+f1ZAFk1mMUWBfRPyLxmg3ozlnmQmlwuZKmn4RLVnjaCqaS1gyQEIYjqxLD2JW2 8dAvI5SmdlsJjzyknEI6UQ/5hofKCUHn7fRhvCVqC8RpoYC8aUxxYW++dh+k2Ekq/ueC l6rZJ3J4PC857kKFFtW1SRN2cS74bext31u0H6hkEUeRpO8qPzxkNaisuRETalZGmhlx H1IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:in-reply-to:user-agent; bh=o9OK/KSdIv9E/B1ffRtWt+ObJcCTTGZ0MP5YkggrOVI=; b=NLBjQDzErcWrOOUJfADA6BMHoiOPgnaz2RJMU5AlEIkl9ggGpCY/vTSuWgHKIhmL3f zD8C7DYqylLMcQQlI8/DmxhT/LyWSLO9RrUYUqQoKxdgBybHDAgrzAe1I2oTBad/7+eP JbZr984gK8jz/X/YOsPoyb8xwFPXU/Ow13WHcTjmYoQyeq8TWQPAJ37NdRaTlSCIWK7O iJL9qD7/7lI7kOHAavbiastPLesRxlhlqu9QfzcgCiI0F12FaISEAjVfk00d9KEWO2dW iLDKiApOSM3rQx/KLSWAwQ5y4+w4bqiP9K70mJefpmyzfJpXM0aYvSwJJLeYBXjsJccH aeog== X-Gm-Message-State: AHQUAuYpazUkxkrIPn23VfnYQtJTKm4H8UoW0BgED7gMXmnN3eiwVL+O A1pOCSrEvLDMOdFn5eQn6yfY5VFLKNk= X-Google-Smtp-Source: AHgI3IZ3EIgiRTpMGVtlKslgan4itQzUEfbgp9UGWD00SLioA2FCSWjK7Xedrcny93zAOIx7e6jwow== X-Received: by 2002:a24:3257:: with SMTP id j84mr3126254ita.173.1550178216651; Thu, 14 Feb 2019 13:03:36 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id 125sm1614217itk.28.2019.02.14.13.03.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 13:03:35 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id C8AAB800997; Thu, 14 Feb 2019 15:03:34 -0600 (CST) Date: Thu, 14 Feb 2019 15:03:34 -0600 From: Justin Pryzby To: Luis Carril , Andres Freund Cc: pgsql-performance@lists.postgresql.org Subject: Re: JIT overhead slowdown Message-ID: <20190214210334.GA1732@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190118164254.p3p6gogijf3dh7q6@alap3.anarazel.de> User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On Fri, Jan 18, 2019 at 02:12:23PM +0000, Luis Carril wrote: > we noticed that in the presence of a schema with many partitions the jitting overhead penalizes the total query execution time so much that the planner should have decided not to jit at all. For example without jitting we go a 8.3 s execution time and with jitting enabled 13.8 s. ... > Is this behavior expected? Is the cost function for jitting missing some circumstances? On Fri, Jan 18, 2019 at 08:42:54AM -0800, Andres Freund wrote: > The costing doesn't take the effect of overhead of repeated JITing in > each worker into account. I could give you a test patch that does, if > you want to play around with it? On Fri, Jan 18, 2019 at 06:02:43PM +0000, Luis Carril wrote: > yes please it would be much apreciated. I'm also interested to try that ; on re-enabling JIT in 11.2, I see that JITed queries seem to be universally slower than non-JIT. I found that was discussed here: https://www.postgresql.org/message-id/20180822161241.je6nghzjsktbb57b%40alap3.anarazel.de https://www.postgresql.org/message-id/20180624203633.uxirvmigzdhcyjsd%40alap3.anarazel.de Multiplying JIT cost by nworkers seems like an obvious thing to try, but I wondered whether it's really correct? Certainly repeated JITing takes N times more CPU time, but doesn't make the query slower...unless the CPU resources are starved and limiting ? Justin