| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
| Cc: | Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Geoghegan <peter(dot)geoghegan(at)crunchydata(dot)com>, Joe Conway <joe(at)crunchydata(dot)com> |
| Subject: | Re: Changing SQL Inlining Behaviour (or...?) |
| Date: | 2019-01-19 20:44:09 |
| Message-ID: | 13430.1547930649@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
> Is there a rule of thumb we can use in costing our wrappers to ensure that they always inline?
Not really, which is a weak spot of this whole approach.
In particular, if you just make procost really big, you risk screwing
things up rather badly in cases where inlining fails for whatever reason.
Also I'm slightly concerned that we'd end up with an "arms race"
where different functions are all trying to out-cost each other.
I don't know whether you've actually tried to use a fix along this line?
It might be good to experiment with whether you can actually improve
matters for PostGIS before we commit to supporting this hack.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-01-19 20:53:33 | Re: pgsql: Remove references to Majordomo |
| Previous Message | Paul Ramsey | 2019-01-19 20:31:05 | Re: Changing SQL Inlining Behaviour (or...?) |