[postgis-devel] SQL Wrapper Inlining

Paul Ramsey pramsey at cleverelephant.ca
Wed Oct 31 09:17:30 PDT 2018


FYI, The conversation about our inlining problem is live again.

https://www.postgresql.org/message-id/10355.1540926295@sss.pgh.pa.us <https://www.postgresql.org/message-id/10355.1540926295@sss.pgh.pa.us>

I raised our issues with both Tom and Andres, and also our tentative solution of just marking functions we wanted to inline as INLINE. Unsurprisingly, neither of them was super excited to add syntax to solve what they see as an implementation problem. Fortunately, Tom has brushed off his thoughts around fixing value caching behaviour so that more aggressive inlining behaviour becomes a reasonable default, which solves our problem as a side effect to a general improvement to PgSQL efficiency.

(side note on WTF I’m talking about:

In a query with repeated terms on the target list:

SELECT myfunc(this), myfunc(this), that FROM mytable

The return value of myfunc will be calculated twice. That’s, clearly, not an efficient thing to do. This is why the inlining logic, when presented with a function that does something like:

myfunc(this) -> select func2($1) and func2($1)

will say, if func2 is costly, “nope, not going to inline that, it causes a double calculation!”. If the handling of repeated function calls on the target list was smarter, the inliner could accept the above case, and we’d be happy campers.

end side note)

Anyways, keep an eye on that thread, and see if you can understand it :)

ATB,
P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181031/f13a6541/attachment.html>


More information about the postgis-devel mailing list