| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: bad JIT decision |
| Date: | 2020-07-27 23:02:56 |
| Message-ID: | 20200727230256.GA31992@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 2020-Jul-27, Scott Ribe wrote:
> > On Jul 27, 2020, at 4:00 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> >
> > I don't quite understand why is it that a table with 1000 partitions
> > means that JIT compiles the thing 1000 times. Sure, it is possible that
> > some partitions have a different column layout, but it seems an easy bet
> > that most cases are going to have identical column layout, and so tuple
> > deforming can be shared. (I'm less sure about sharing a compile of an
> > expression, since the varno would vary. But presumably there's a way to
> > take the varno as an input value for the compiled expr too?) Now I
> > don't actually know how this works so please correct if I misunderstand
> > it.
>
> I'm guessing it's because of inlining. You could optimize a function
> that takes parameters, no problem. But what's happening is inlining,
> with parameters, then optimizing.
Are you saying that if you crank jit_inline_above_cost beyond this
query's total cost, the problem goes away?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2020-07-27 23:54:53 | Re: bad JIT decision |
| Previous Message | Andres Freund | 2020-07-27 23:00:07 | Re: bad JIT decision |