From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Scott Ribe <scott_ribe(at)elevated-dev(dot)com>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: bad JIT decision |
Date: | 2020-07-25 14:23:14 |
Message-ID: | 672183.1595686994@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2020-07-24 18:37:02 -0400, Tom Lane wrote:
>> Yeah. I'm fairly convinced that the v12 defaults are far too low,
>> because we are constantly seeing complaints of this sort.
> I think the issue is more that we need to take into accoutn that the
> overhead of JITing scales ~linearly with the number of JITed
> expressions. And that's not done right now. I've had a patch somewhere
> that had a prototype implementation of changing the costing to be
> #expressions * some_cost, and I think that's a lot more accurate.
Another thing we could try with much less effort is scaling it by the
number of relations in the query. There's already some code in the
plancache that tries to estimate planning effort that way, IIRC.
Such a scaling would be very legitimate for the cost of compiling
tuple-deconstruction code, and for other expressions it'd kind of
amount to an assumption that the expressions-per-table ratio is
roughly constant. If you don't like that, maybe some simple
nonlinear growth rule would work.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-07-25 14:54:18 | Re: bad JIT decision |
Previous Message | Tom Lane | 2020-07-25 14:17:50 | Re: bad JIT decision |