From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Query is over 2x slower with jit=on |
Date: | 2018-08-22 19:02:51 |
Message-ID: | 20180822190251.tkwskkljrhfstrdy@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> >
> > 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
> > multiple the cost limits by the number of workers, to model that. But
> > without the fixed instrumentation that's harder to see...
>
> It depends on the query. It has been shown in other threads that query can
> indeed take longer to run because of JITing : if the cost is too low to fire
> LLVM optimizer, the generated code can be so bad it will be slower than the
> non-JIT executor.
This largely seems to be orthogonal to what I'm talking about.
> Cf for instance a previous discussion here : http://www.postgresql-archive.org/PATCH-LLVM-tuple-deforming-improvements-td6029385.html
I'd wish people stopped using www.postgresql-archive.org. It's *NOT*
postgresql.org maintained, in fact I do not know who does. It does shows
ads when downloading links, which I'm personally not ok with.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Verite | 2018-08-22 20:05:41 | Re: csv format for psql |
Previous Message | Andreas Joseph Krogh | 2018-08-22 18:58:45 | Re: Query is over 2x slower with jit=on |