| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-27 22:00:43 |
| Message-ID: | 20200727220043.GA29801@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 2020-Jul-24, Andres Freund wrote:
> 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.
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.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Ribe | 2020-07-27 22:24:38 | Re: bad JIT decision |
| Previous Message | David Rowley | 2020-07-27 21:50:39 | Re: determine what column(s) form the primary key, in C extention |