Re: Stampede of the JIT compilers

From: James Coleman <jtc331(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, David Pirotte <dpirotte(at)gmail(dot)com>
Subject: Re: Stampede of the JIT compilers
Date: 2023-06-25 02:24:37
Message-ID: CAAaqYe9VSosjFXbW6qXnC9bZgCXsyM7o6dF6z02E41sqvg8wxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jun 24, 2023 at 1:54 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> James Coleman <jtc331(at)gmail(dot)com> writes:
> > 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

I'm happy to withdraw that particular idea. My mental model was along
the lines "this is a startup cost, and then we'll have it cached, so
the higher than expected cost won't matter as much when the system
settles down", and in that scenario limiting the size of the herd can
make sense.

But that's not the broader problem, so...

Regards,
James Coleman

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message James Coleman 2023-06-25 02:27:43 Re: Stampede of the JIT compilers
Previous Message Vik Fearing 2023-06-25 00:14:52 Re: Add support for AT LOCAL