Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f8p7H-0007cD-Ni for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Apr 2018 15:35:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f8p7G-0003cV-KS for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Apr 2018 15:35:26 +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 1f8p7G-0003cM-9u for pgsql-hackers@lists.postgresql.org; Wed, 18 Apr 2018 15:35:26 +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 1f8p79-0002BS-BJ for pgsql-hackers@lists.postgresql.org; Wed, 18 Apr 2018 15:35:25 +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:Message-ID:To:From:Date; bh=ay+tGYzWd8oMFlEb02vmJ4hMAmR5bfvTsg0kx+40CNQ=; b=l3xlbSMtNVCxC1U1G4jaAkdtvXPrYBnhDa73sZVTszHRPz82y6ErjNnMqb5hRyzaTs1+ORqQ1CxU9F50LcwNU0E9+9n7ED7rR14NzvAi7liBJN/oXZhJNYhXCgmwu+uSa/ocVEB/5n3FnHaXiSJrsNdbweGxUGaLWr+xmmWu2zc=; 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 1f8p76-00063N-DK for pgsql-hackers@lists.postgresql.org; Wed, 18 Apr 2018 17:35:18 +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 1f8p7L-0002Zn-8Y for pgsql-hackers@lists.postgresql.org; Wed, 18 Apr 2018 17:35:31 +0200 Date: Wed, 18 Apr 2018 17:35:31 +0200 (CEST) From: Andreas Joseph Krogh To: pgsql-hackers@lists.postgresql.org Message-ID: Subject: Query is over 2x slower with jit=on MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_140_453878836.1524065731163" X-Mailer: Visena Mail 2.1.34 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_140_453878836.1524065731163 Content-Type: multipart/related; boundary="----=_Part_141_1485574795.1524065731163" ------=_Part_141_1485574795.1524065731163 Content-Type: multipart/alternative; boundary="----=_Part_142_1006508615.1524065731173" ------=_Part_142_1006508615.1524065731173 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all. =C2=A0 I don't know whether this is expected or not but I'm experiencing over 2x= =20 slowdown on a large query in PG-11 with JIT=3Don. =C2=A0 (query is a prepared statement executed with "explain analyze execute=20 myprepared(arg1, arg2, ..., argn)") =C2=A0 After 10 executions these are the results (the first 5 executed in > 16s, t= hen=20 the plan changed) =C2=A0 With jit=3Don: https://explain.depesz.com/s/vYB Planning Time: 0.336 ms=20 JIT: =C2=A0Functions: 716 =C2=A0Generation Time: 78.404 ms =C2=A0Inlining: false =C2=A0Inlining Time: 0.000 ms =C2=A0Optimization: false =C2=A0Optimization Time: 43.916 ms =C2=A0Emission Time: 600.031 ms Execution Time: 2035.150 ms (385 rows) =C2=A0 With jit=3Doff: https://explain.depesz.com/s/X6mA Planning Time: 0.371 ms=20 Execution Time: 833.941 ms (377 rows) =C2=A0 Both are master as of=C2=A055d26ff638f063fbccf57843f2c27f9795895a5c =C2=A0 The query largely consists of CTEs with aggregation which are FULL OUTER=20 JOIN'ed. =C2=A0 On v10 the query executes in: Execution time: 1159.628 ms =C2=A0 So v11 (with jit=3Doff) is about 25% faster (due to parallel hash-join I th= ink),=20 which is nice! =C2=A0 What's the deal with jit making it slower? =C2=A0 -- Andreas Joseph Krogh ------=_Part_142_1006508615.1524065731173 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all.
=C2=A0
I don't know whether this is expected or not but I'm experiencing over= 2x slowdown on a large query in PG-11 with JIT=3Don.
=C2=A0
(query is a prepared statement executed with "explain analyze exe= cute myprepared(arg1, arg2, ..., argn)")
=C2=A0
After 10 executions these are the results (the first 5 executed in >= ; 16s, then the plan changed)
=C2=A0
With jit=3Don:
https://explain.depesz.com/s/vYB
Planning Time: 0.336 ms
JIT:
=C2=A0Functions: 716
=C2=A0Generation Time: 78.404 ms
=C2=A0Inlining: false
=C2=A0Inlining Time: 0.000 ms
=C2=A0Optimization: false
=C2=A0Optimization Time: 43.916 ms
=C2=A0Emission Time: 600.031 ms
Execution Time: 2035.150 ms
(385 rows)
=C2=A0
With jit=3Doff:
https://explain.depesz.com/s/X6mA
Planning Time: 0.371 ms
Execution Time: 833.941 ms
(377 rows)
=C2=A0
Both are master as of=C2=A055d26ff638f063fbccf57843f2c27f9795895a5c
=C2=A0
The query largely consists of CTEs with aggregation which are FULL OUT= ER JOIN'ed.
=C2=A0
On v10 the query executes in:
Execution time: 1159.628 ms
=C2=A0
So v11 (with jit=3Doff) is about 25% faster (due to parallel hash-join= I think), which is nice!
=C2=A0
What's the deal with jit making it slower?
=C2=A0
">
--
Andreas Joseph Krogh
------=_Part_142_1006508615.1524065731173-- ------=_Part_141_1485574795.1524065731163-- ------=_Part_140_453878836.1524065731163--