| From: | Scott Ribe <scott_ribe(at)elevated-dev(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(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 22:24:38 |
| Message-ID: | 690D93FA-4A30-422D-94C3-18A089B8AEFE@elevated-dev.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2020-07-27 23:00:07 | Re: bad JIT decision |
| Previous Message | Alvaro Herrera | 2020-07-27 22:00:43 | Re: bad JIT decision |