From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: JIT compiling with LLVM v12 |
Date: | 2018-08-22 22:15:29 |
Message-ID: | 3755.1534976129@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2018-08-22 06:20:21 +0000, Noah Misch wrote:
>> Regardless of the choice of jit={on|off} default, these numbers tell me that
>> some or all of jit_*_cost defaults are too low.
> I don't think it really shows that. The reason that JITing gets started
> there is that the tables aren't analyzed and we end up with crazy ass
> estimates about the cost of the queries. No useful setting of the cost
> limits will protect against that... :(
I don't buy that line of argument one bit. No, we generally don't
analyze most of the regression test tables, but the planner still
knows that they're not very large. If JIT is kicking in for those
queries, the defaults are set wrong. Additional evidence for the
defaults being wrong is the number of reports we've had of JIT making
things slower.
I was OK with that happening during early beta, on the grounds of getting
more testing for the JIT code; but it's time to fix the numbers.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2018-08-22 22:29:58 | Re: Query is over 2x slower with jit=on |
Previous Message | Nikita Glukhov | 2018-08-22 21:29:17 | Re: jsonpath |