Re: Stampede of the JIT compilers
От | Tom Lane |
---|---|
Тема | Re: Stampede of the JIT compilers |
Дата | |
Msg-id | 260846.1687629293@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Stampede of the JIT compilers (James Coleman <jtc331@gmail.com>) |
Ответы |
Re: Stampede of the JIT compilers
(David Rowley <dgrowleyml@gmail.com>)
Re: Stampede of the JIT compilers (James Coleman <jtc331@gmail.com>) Re: Stampede of the JIT compilers (Michael Banck <mbanck@gmx.net>) Re: Stampede of the JIT compilers (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
James Coleman <jtc331@gmail.com> writes: > On Sat, Jun 24, 2023 at 7:40 AM Tomas Vondra > <tomas.vondra@enterprisedb.com> wrote: >> On 6/24/23 02:33, David Rowley wrote: >>> On Sat, 24 Jun 2023 at 02:28, James Coleman <jtc331@gmail.com> wrote: >>>> There are a couple of issues here. I'm sure it's been discussed >>>> before, and it's not the point of my thread, but I can't help but note >>>> that the default value of jit_above_cost of 100000 seems absurdly low. >>>> On good hardware like we have even well-planned queries with costs >>>> well above that won't be taking as long as JIT compilation does. >>> It would be good to know your evidence for thinking it's too low. > It's definitely possible that I stated this much more emphatically > than I should have -- it was coming out of my frustration with this > situation after all. I think there is *plenty* of evidence that it is too low, or at least that for some reason we are too willing to invoke JIT when the result is to make the overall cost of a query far higher than it is without. Just see all the complaints on the mailing lists that have been resolved by advice to turn off JIT. You do not even have to look further than our own regression tests: on my machine with current HEAD, "time make installcheck-parallel" reports real 0m8.544s user 0m0.906s sys 0m0.863s for a build without --with-llvm, and real 0m13.211s user 0m0.917s sys 0m0.811s for a build with it (and all JIT settings left at defaults). If you do non-parallel "installcheck" the ratio is similar. I don't see how anyone can claim that 50% slowdown is just fine. I don't know whether raising the default would be enough to fix that in a nice way, and I certainly don't pretend to have a specific value to offer. But it's undeniable that we have a serious problem here, to the point where JIT is a net negative for quite a few people. > In that context capping the number of backends compiling, particularly > where plans (and JIT?) might be cached, could well save us (depending > on workload). TBH I do not find this proposal attractive in the least. We have a problem here even when you consider a single backend. If we fixed that, so that we don't invoke JIT unless it really helps, then it's not going to help less just because you have a lot of backends. Plus, the overhead of managing a system-wide limit is daunting. regards, tom lane
В списке pgsql-hackers по дате отправления: