Re: Query is over 2x slower with jit=on

Hi, On 2018-10-01 00:32:18 -0700, Lukas Fittl wrote: > On Tue, Sep 25, 2018 at 1:17 PM, Andres Freund wrote: > > > > I've pushed the change without that bit - it's just a few additional > > lines if we want to change that. > > > > It seems that since this commit, JIT statistics are now only

Re: Query is over 2x slower with jit=on

On Tue, Sep 25, 2018 at 1:17 PM, Andres Freund wrote: > > I've pushed the change without that bit - it's just a few additional > lines if we want to change that. > It seems that since this commit, JIT statistics are now only being printed for parallel query plans. This is due to ExplainPrintJIT

Re: Query is over 2x slower with jit=on

On 2018-09-26 23:45:35 +0530, Amit Khandekar wrote: > On Tue, 25 Sep 2018 at 14:17, Andres Freund wrote: > > > > On 2018-09-18 10:03:02 +0530, Amit Khandekar wrote: > > > Attached v3 patch that does the above change. > > > > Attached is a revised version of that patch. I've changed quite a few >

Re: Query is over 2x slower with jit=on

On Tue, 25 Sep 2018 at 14:17, Andres Freund wrote: > > On 2018-09-18 10:03:02 +0530, Amit Khandekar wrote: > > Attached v3 patch that does the above change. > > Attached is a revised version of that patch. I've changed quite a few > things: > - I've reverted the split of "base" and "provider

Re: Query is over 2x slower with jit=on

Hi, On 2018-09-25 12:50:34 -0700, Andres Freund wrote: > On 2018-09-25 01:47:49 -0700, Andres Freund wrote: > > Planning Time: 0.152 ms > > JIT: > > Functions: 4 > > Options: Inlining true, Optimization true, Expressions true, Deforming > > true > > Timing: Generation 0.955 ms, Inlining

Re: Query is over 2x slower with jit=on

Hi, On 2018-09-25 01:47:49 -0700, Andres Freund wrote: > Forcing parallelism and JIT to be on, I get: > > postgres[20216][1]=# EXPLAIN (ANALYZE, VERBOSE, BUFFERS) SELECT count(*) FROM > pg_class; > > Finalize Aggregate (cost=15.43..15.44 rows=1 width=8) (actual > time=183.282..183.282 rows=1

Re: Query is over 2x slower with jit=on

On 2018-09-18 10:03:02 +0530, Amit Khandekar wrote: > Attached v3 patch that does the above change. Attached is a revised version of that patch. I've changed quite a few things: - I've reverted the split of "base" and "provider specific" contexts - I don't think it really buys us anything

Re: Query is over 2x slower with jit=on

Hi, On 2018-09-19 20:39:22 -0700, Andres Freund wrote: > On 2018-09-19 23:26:52 -0400, Tom Lane wrote: > > That's going in the right direction. Personally I'd make the last line > > more like > > > > Times: generation 0.680 ms, inlining 7.591 ms, optimization 20.522 ms, > > emission 14.607

Re: Query is over 2x slower with jit=on

On 2018-09-20 09:07:21 -0400, Stephen Frost wrote: > Greetings, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2018-09-19 23:26:52 -0400, Tom Lane wrote: > > > Andres Freund writes: > > > > JIT: > > > > Functions: 2 > > > > Generation Time: 0.680 ms > > > > Inlining: true > > > >

Re: Query is over 2x slower with jit=on

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2018-09-19 23:26:52 -0400, Tom Lane wrote: > > Andres Freund writes: > > > JIT: > > > Functions: 2 > > > Generation Time: 0.680 ms > > > Inlining: true > > > Inlining Time: 7.591 ms > > > Optimization: true > > >

Re: Query is over 2x slower with jit=on

čt 20. 9. 2018 v 5:39 odesílatel Andres Freund napsal: > On 2018-09-19 23:26:52 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On 2018-09-17 17:50:15 -0400, Tom Lane wrote: > > >> Just to throw a contrarian opinion into this: I find the current > EXPLAIN > > >> output for JIT to be

Re: Query is over 2x slower with jit=on

On 2018-09-19 23:26:52 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-09-17 17:50:15 -0400, Tom Lane wrote: > >> Just to throw a contrarian opinion into this: I find the current EXPLAIN > >> output for JIT to be insanely verbose already. > > > Hm, it'd have been nice to get that

Re: Query is over 2x slower with jit=on

Andres Freund writes: > On 2018-09-17 17:50:15 -0400, Tom Lane wrote: >> Just to throw a contrarian opinion into this: I find the current EXPLAIN >> output for JIT to be insanely verbose already. > Hm, it'd have been nice to get that feedback a little bit earlier, I did > inquire... >

Re: Query is over 2x slower with jit=on

Hi, On 2018-09-17 17:50:15 -0400, Tom Lane wrote: > Amit Khandekar writes: > > On 11 September 2018 at 14:50, Amit Khandekar > > wrote: > >> On 10 September 2018 at 21:39, Andres Freund wrote: > >>> On 2018-09-10 15:42:55 +0530, Amit Khandekar wrote: > I think we better show per-worker

Re: Query is over 2x slower with jit=on

On 18 September 2018 at 03:20, Tom Lane wrote: > Amit Khandekar writes: > I think we better show per-worker jit info also. > > Just to throw a contrarian opinion into this: I find the current EXPLAIN > output for JIT to be insanely verbose already. One option is to make the jit info

Re: Query is over 2x slower with jit=on

On 14 September 2018 at 16:48, Amit Khandekar wrote: > On 11 September 2018 at 14:50, Amit Khandekar wrote: >> On 10 September 2018 at 21:39, Andres Freund wrote: /* + * Add up the workers' JIT instrumentation from dynamic shared memory. + */ +static void

Re: Query is over 2x slower with jit=on

Amit Khandekar writes: > On 11 September 2018 at 14:50, Amit Khandekar wrote: >> On 10 September 2018 at 21:39, Andres Freund wrote: >>> On 2018-09-10 15:42:55 +0530, Amit Khandekar wrote: I think we better show per-worker jit info also. Just to throw a contrarian opinion into this: I

Re: Query is over 2x slower with jit=on

On 11 September 2018 at 14:50, Amit Khandekar wrote: > On 10 September 2018 at 21:39, Andres Freund wrote: >> Hi, >> >> On 2018-09-10 15:42:55 +0530, Amit Khandekar wrote: >>> Attached is a patch that accumulates the per-worker jit counters into >>> the leader process. >> >> Thanks! >> >> >>> I

Re: Query is over 2x slower with jit=on

On 10 September 2018 at 21:39, Andres Freund wrote: > Hi, > > On 2018-09-10 15:42:55 +0530, Amit Khandekar wrote: >> Attached is a patch that accumulates the per-worker jit counters into >> the leader process. > > Thanks! > > >> I think we better show per-worker jit info also. The current patch

Re: Query is over 2x slower with jit=on

Hi, On 2018-09-10 15:42:55 +0530, Amit Khandekar wrote: > Attached is a patch that accumulates the per-worker jit counters into > the leader process. Thanks! > I think we better show per-worker jit info also. The current patch > does not show that. I think it would be easy to continue on the

Re: Query is over 2x slower with jit=on

On 22 August 2018 at 22:21, Andres Freund wrote: > On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote: >> Just to be clear; The query really runs slower (wall-clock time), it's not >> just the timing. > > I bet it's not actually running slower, it "just" takes longer to start > up due to

Sv: Re: Query is over 2x slower with jit=on

På torsdag 23. august 2018 kl. 09:14:56, skrev Andreas Joseph Krogh < andr...@visena.com >: På torsdag 23. august 2018 kl. 03:00:42, skrev Jonathan S. Katz < jk...@postgresql.org >: > On Aug 22, 2018, at 7:13 PM, Andres Freund wrote:

Re: Query is over 2x slower with jit=on

På torsdag 23. august 2018 kl. 03:00:42, skrev Jonathan S. Katz < jk...@postgresql.org >: > On Aug 22, 2018, at 7:13 PM, Andres Freund wrote: [snip] > For the archives sake: This likely largely is the consequence of > building with LLVM's expensive assertions

Re: Query is over 2x slower with jit=on

> On Aug 22, 2018, at 7:13 PM, Andres Freund wrote: > > On 2018-08-22 18:29:58 -0400, Jonathan S. Katz wrote: >> >>> On Aug 22, 2018, at 2:58 PM, Andreas Joseph Krogh >>> wrote: >>> >>> På onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund >>> mailto:and...@anarazel.de>>: >>> On

Re: Query is over 2x slower with jit=on

On 2018-08-22 18:29:58 -0400, Jonathan S. Katz wrote: > > > On Aug 22, 2018, at 2:58 PM, Andreas Joseph Krogh > > wrote: > > > > På onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund > > mailto:and...@anarazel.de>>: > > On 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote: > > > I

Re: Query is over 2x slower with jit=on

> On Aug 22, 2018, at 2:58 PM, Andreas Joseph Krogh wrote: > > På onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund > mailto:and...@anarazel.de>>: > On 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote: > > I thought JITing of prepared queries happended once (in "prepare") > > No,

Re: Query is over 2x slower with jit=on

On 2018-08-22 20:48:48 +0200, Pierre Ducroquet wrote: > On Wednesday, August 22, 2018 6:51:55 PM CEST Andres Freund wrote: > > On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote: > > > Just to be clear; The query really runs slower (wall-clock time), it's not > > > just the timing. > > > >

Re: Query is over 2x slower with jit=on

På onsdag 22. august 2018 kl. 20:52:05, skrev Andres Freund mailto:and...@anarazel.de>>: On 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote: > I thought JITing of prepared queries happended once (in "prepare") No, it happens when the first JITed function is executed. >  so it didn't

Re: Query is over 2x slower with jit=on

On 2018-08-22 19:51:12 +0200, Andreas Joseph Krogh wrote: > I thought JITing of prepared queries happended once (in "prepare") No, it happens when the first JITed function is executed. >  so it didn't have to do the JITing every time the query is > executed. Isn't the previously generated

Re: Query is over 2x slower with jit=on

On Wednesday, August 22, 2018 6:51:55 PM CEST Andres Freund wrote: > On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote: > > Just to be clear; The query really runs slower (wall-clock time), it's not > > just the timing. > > I bet it's not actually running slower, it "just" takes longer to

Sv: Re: Query is over 2x slower with jit=on

På onsdag 22. august 2018 kl. 18:51:55, skrev Andres Freund mailto:and...@anarazel.de>>: On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote: > Just to be clear; The query really runs slower (wall-clock time), it's not > just the timing. I bet it's not actually running slower, it "just"

Re: Query is over 2x slower with jit=on

On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote: > Just to be clear; The query really runs slower (wall-clock time), it's not > just the timing. I bet it's not actually running slower, it "just" takes longer to start up due to the JITing in each worker. I suspect what we should do is to

Sv: Re: Query is over 2x slower with jit=on

På onsdag 22. august 2018 kl. 18:12:41, skrev Andres Freund mailto:and...@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 wrote: > > Not convinced that that is true - the issue is more likely that JIT work in workers is

Re: Query is over 2x slower with jit=on

> On Aug 22, 2018, at 12:12 PM, Andres Freund wrote: > > Hi, > > On 2018-04-18 18:37:30 -0400, Robert Haas wrote: >> On Wed, Apr 18, 2018 at 3:29 PM, Andres Freund wrote: >>> Not convinced that that is true - the issue is more likely that JIT work in >>> workers is counted as execute time...

Re: Query is over 2x slower with jit=on

Hi, On 2018-04-18 18:37:30 -0400, Robert Haas wrote: > On Wed, Apr 18, 2018 at 3:29 PM, Andres Freund wrote: > > Not convinced that that is true - the issue is more likely that JIT work in > > workers is counted as execute time... Gotta add that somehow, not sure what > > the best way would

Sv: Sv: Re: Query is over 2x slower with jit=on

På onsdag 18. april 2018 kl. 18:26:03, skrev Andreas Joseph Krogh < andr...@visena.com >: På onsdag 18. april 2018 kl. 17:50:55, skrev Andres Freund >: On 2018-04-18 17:35:31 +0200, Andreas Joseph Krogh wrote: > With

Re: Query is over 2x slower with jit=on

On Wed, Apr 18, 2018 at 3:29 PM, Andres Freund wrote: > Not convinced that that is true - the issue is more likely that JIT work in > workers is counted as execute time... Gotta add that somehow, not sure what > the best way would be. Oh, that does seem like something that

Re: Query is over 2x slower with jit=on

On April 18, 2018 12:16:35 PM PDT, Robert Haas wrote: >On Wed, Apr 18, 2018 at 11:50 AM, Andres Freund >wrote: >> JIT has cost, and sometimes it's not beneficial. Here our heuristics >> when to JIT appear to be a bit off. In the parallel world it's

Re: Query is over 2x slower with jit=on

On Wed, Apr 18, 2018 at 11:50 AM, Andres Freund wrote: > JIT has cost, and sometimes it's not beneficial. Here our heuristics > when to JIT appear to be a bit off. In the parallel world it's worse > because the JITing is duplicated for parallel workers atm. It seems like

Re: Query is over 2x slower with jit=on

On April 18, 2018 9:50:48 AM PDT, Chapman Flack wrote: >On 04/18/2018 12:27 PM, Simon Riggs wrote: > >> Please change the name of the "JIT" parameter to something meaningful >> to humans before this gets too far into the wild. >> >> SSL is somewhat understandable because

Re: Query is over 2x slower with jit=on

On 04/18/2018 12:27 PM, Simon Riggs wrote: > Please change the name of the "JIT" parameter to something meaningful > to humans before this gets too far into the wild. > > SSL is somewhat understandable because its not a Postgres-private term. JIT is hardly a Postgres-private term. It's a

Re: Query is over 2x slower with jit=on

On 18 April 2018 at 16:50, Andres Freund wrote: > On 2018-04-18 17:35:31 +0200, Andreas Joseph Krogh wrote: >> With jit=on: >> https://explain.depesz.com/s/vYB >> Planning Time: 0.336 ms >> JIT: >> Functions: 716 >> Generation Time: 78.404 ms >> Inlining: false >>

Sv: Re: Query is over 2x slower with jit=on

På onsdag 18. april 2018 kl. 17:50:55, skrev Andres Freund >: On 2018-04-18 17:35:31 +0200, Andreas Joseph Krogh wrote: > With jit=on: > https://explain.depesz.com/s/vYB > Planning Time: 0.336 ms >  JIT: >   Functions: 716 >   Generation Time:

Re: Query is over 2x slower with jit=on

On 2018-04-18 17:35:31 +0200, Andreas Joseph Krogh wrote: > With jit=on: > https://explain.depesz.com/s/vYB > Planning Time: 0.336 ms > JIT: >  Functions: 716 >  Generation Time: 78.404 ms >  Inlining: false >  Inlining Time: 0.000 ms >  Optimization: false >  Optimization Time: 43.916 ms

Query is over 2x slower with jit=on

Hi all.   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=on.   (query is a prepared statement executed with "explain analyze execute myprepared(arg1, arg2, ..., argn)")   After 10 executions these are the results (the first 5