Re: Changing SQL Inlining Behaviour (or...?)

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

In response to


Browse pgsql-hackers by date

  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...?)