Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fsYJx-0007i9-7H for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Aug 2018 18:57:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fsYJu-00084Y-UH for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Aug 2018 18:57:30 +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.89) (envelope-from ) id 1fsYJu-00084R-Iu for pgsql-hackers@lists.postgresql.org; Wed, 22 Aug 2018 18:57:30 +0000 Received: from post.visena.com ([46.226.10.50]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fsYJr-0007jS-QD for pgsql-hackers@lists.postgresql.org; Wed, 22 Aug 2018 18:57:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=visena.com; s=20141101.wh; h=Content-Type:MIME-Version:Subject:In-Reply-To:Message-ID:Cc:To:From:Date; bh=yoGX5Un2j77T9d1nufczDXqQhj0tTlFukJ5V2o5k2nk=; b=bdC7tLg2lNSd6UvJkGBweADxAzfsRDg2Y5H/NIMJnimwILLAAzsQwbAdQEccWq5844QnPfdeimdL4SscvZAjvW9caZAtKNnQW99OgwwoByXPVQy228WRb2AYbJIZJscbj3ZmabX0uEPW8MDcXgKR7MjpluOEiZ0fL0/CEpxErhU=; Received: from [10.0.1.10] (helo=tc7-visena.wh.internal.visena.com) by post.visena.com with esmtp (Exim 4.82) (envelope-from ) id 1fsYJk-00057T-Kn; Wed, 22 Aug 2018 20:57:22 +0200 Received: from localhost ([127.0.0.1] helo=tc7-visena.wh.internal.visena.com) by tc7-visena.wh.internal.visena.com with esmtp (Exim 4.86_2) (envelope-from ) id 1fsYL7-0004DI-E8; Wed, 22 Aug 2018 20:58:45 +0200 Date: Wed, 22 Aug 2018 20:58:45 +0200 (CEST) From: Andreas Joseph Krogh To: Andres Freund Cc: Robert Haas , Alvaro Herrera , "Jonathan S. Katz" , PostgreSQL Hackers Message-ID: In-Reply-To: <20180822185205.dtfe722isnkdlfgg@alap3.anarazel.de> Subject: Re: Query is over 2x slower with jit=on MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_215_1779240843.1534964325331" X-Mailer: Visena Mail 2.1.103 X-Spam-Score: -1.0 X-Spam-Report: SpamAssasin (score=-1.0, required 5.0 ALL_TRUSTED=-1,HTML_MESSAGE=0.001) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------=_Part_215_1779240843.1534964325331 Content-Type: multipart/related; boundary="----=_Part_216_684368033.1534964325331" ------=_Part_216_684368033.1534964325331 Content-Type: multipart/alternative; boundary="----=_Part_217_52043627.1534964325342" ------=_Part_217_52043627.1534964325342 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable P=C3=A5 onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund >: On 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote: > I thought=C2=A0JITing of prepared=C2=A0queries happended once (in "prepa= re") No, it happens when the first JITed function is executed. > =C2=A0so it didn't have to do the JITing every time the query is > executed. Isn't the=C2=A0previously generated bytecode usable for > subsequent queries? No, not currently. There's some reasons preventing that (primarily that we currently rely on addresses of certain things not to change during execution). There's ongoing work to change that, but that's certainly not going to be ready for v11. Greetings, Andres Freund =C2=A0 =C2=A0 Ok, thanks for clarifying. =C2=A0 -- Andreas Joseph Krogh ------=_Part_217_52043627.1534964325342 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable
P=C3=A5 onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund <<= a href=3D"mailto:andres@anarazel.de">andres@anarazel.de>:
On = 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote:
> I thought=C2=A0JITing of prepared=C2=A0queries happended once (in &quo= t;prepare")

No, it happens when the first JITed function is executed.


> =C2=A0so it didn't have to do the JITing every time the query is
> executed. Isn't the=C2=A0previously generated bytecode usable for
> subsequent queries?

No, not currently. There's some reasons preventing that (primarily that
we currently rely on addresses of certain things not to change during
execution). There's ongoing work to change that, but that's certainly
not going to be ready for v11.

Greetings,

Andres Freund
=C2=A0
=C2=A0
Ok, thanks for clarifying.
=C2=A0
">
--
Andreas Joseph Krogh
------=_Part_217_52043627.1534964325342-- ------=_Part_216_684368033.1534964325331-- ------=_Part_215_1779240843.1534964325331--