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 1fsW8x-0000uv-9e for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Aug 2018 16:38:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fsW8v-0000lA-Ov for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Aug 2018 16:38:01 +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 1fsW8v-0000kz-Hv for pgsql-hackers@lists.postgresql.org; Wed, 22 Aug 2018 16:38:01 +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 1fsW8t-0004ZN-LR for pgsql-hackers@lists.postgresql.org; Wed, 22 Aug 2018 16:38:01 +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=ma3F+d+jIs89xUpcvrfC1VjoZCXwr2cvLpvuxEXNJyk=; b=KF9q+KsB1SFOb8Fg1tc2dEDUPJjLyrmP1FcUC1JO7Q//YbXLoV5LsrfkBUmMunAoMlOpSLxZQB5SN+ftcvwmVlIIealloG+tVASuXFfVTcgGq5IDsf7fYbdcLfGV19zrrJlZbSBymt3fedv6h2dn/cGw97oj5sS5y5jJ34w3vlU=; 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 1fsW8n-00036w-OX; Wed, 22 Aug 2018 18:37:55 +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 1fsWAA-0006NP-Fq; Wed, 22 Aug 2018 18:39:18 +0200 Date: Wed, 22 Aug 2018 18:39:18 +0200 (CEST) From: Andreas Joseph Krogh To: Andres Freund Cc: Robert Haas , Alvaro Herrera , "Jonathan S. Katz" , PostgreSQL Hackers Message-ID: In-Reply-To: <20180822161241.je6nghzjsktbb57b@alap3.anarazel.de> Subject: Sv: Re: Query is over 2x slower with jit=on MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_165_1349528865.1534955958375" 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_165_1349528865.1534955958375 Content-Type: multipart/related; boundary="----=_Part_166_1251246492.1534955958376" ------=_Part_166_1251246492.1534955958376 Content-Type: multipart/alternative; boundary="----=_Part_167_1515651127.1534955958388" ------=_Part_167_1515651127.1534955958388 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable P=C3=A5 onsdag 22. august 2018 kl. 18:12:41, skrev Andres Freund >: Hi, On 2018-04-18 18:37:30 -0400, Robert Haas wrote: > On Wed, Apr 18, 2018 at 3:29 PM, Andres Freund wrot= e: > > Not convinced that that is true - the issue is more likely that JIT wo= rk=20 in workers is counted as execute time... Gotta add that somehow, not sure w= hat=20 the best way would be. > > Oh, that does seem like something that should be fixed.=C2=A0 If that's > what is happening here, it's bound to confuse a lot of people. > Probably you need to add some code to > ExecParallelRetrieveInstrumentation. I had lost track of this, and we unfortunately hadn't added an open item back then.=C2=A0 I think we should add it now? RMT (with me recused), do you think we should accept the new code fixing this would entail? And thus that this should be an open item? It's arguably a new feature, although I don't find that a terribly convincing position. Greetings, Andres Freund =C2=A0 Just to be clear; The query=C2=A0really=C2=A0runs slower (wall-clock time),= it's not=20 just the timing. =C2=A0 -- Andreas Joseph Krogh ------=_Part_167_1515651127.1534955958388 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: quoted-printable
P=C3=A5 onsdag 22. august 2018 kl. 18:12:41, skrev Andres Freund <<= a href=3D"mailto:andres@anarazel.de">andres@anarazel.de>:
Hi,=

On 2018-04-18 18:37:30 -0400, Robert Haas wrote:
> On Wed, Apr 18, 2018 at 3:29 PM, Andres Freund <andres@anarazel.de&= gt; wrote:
> > Not convinced that that is true - the issue is more likely that J= IT work in workers is counted as execute time... Gotta add that somehow, no= t sure what the best way would be.
>
> Oh, that does seem like something that should be fixed.=C2=A0 If that'= s
> what is happening here, it's bound to confuse a lot of people.
> Probably you need to add some code to
> ExecParallelRetrieveInstrumentation.

I had lost track of this, and we unfortunately hadn't added an open item back then.=C2=A0 I think we should add it now?

RMT (with me recused), do you think we should accept the new code fixing this would entail? And thus that this should be an open item? It's
arguably a new feature, although I don't find that a terribly convincing position.

Greetings,

Andres Freund
=C2=A0
Just to be clear; The query=C2=A0really=C2=A0runs slower (wal= l-clock time), it's not just the timing.
=C2=A0
">
--
Andreas Joseph Krogh
------=_Part_167_1515651127.1534955958388-- ------=_Part_166_1251246492.1534955958376-- ------=_Part_165_1349528865.1534955958375--