<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 10, 2018, at 11:15 AM, Paul Norman <<a href="mailto:penorman@mac.com" class="">penorman@mac.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">I don't recall any problems with the wrapper functions and inlining when I set the costs for the first batch of functions. I can take another look this week and measure some more functions.</div></div></blockquote><div><br class=""></div><div>It’s a little subtle to trigger, but it definitely happens for both our functions and for built-ins.</div><div><br class=""></div><div><a href="https://www.postgresql.org/message-id/CACowWR2kuB_yApPhB=zUQ_rKqN5NpdAvNfQqYZ0PhRPBVCbz6g@mail.gmail.com" class="">https://www.postgresql.org/message-id/CACowWR2kuB_yApPhB%3DzUQ_rKqN5NpdAvNfQqYZ0PhRPBVCbz6g%40mail.gmail.com</a></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div dir="auto" class=""><div dir="auto" class="">Do we have a list of what functions still need accurate costs?</div></div></blockquote><div><br class=""></div><div>I don’t know that it’s a matter of “accurate” costs, it’s a matter of “higher” costs, otherwise we end up missing out on parallelism for queries on fairly small tables, tables that PgSQL considers not worth parallelizing. See some of the examples in <a href="http://blog.cleverelephant.ca/2017/10/parallel-postgis-2.html" class="">http://blog.cleverelephant.ca/2017/10/parallel-postgis-2.html</a> where ST_Area() has to be costed to 100 to get a parallel plan. It’s well worth it and displays linear improvements, so the parallel overhead of going parallel for “only” 70K records is basically invisible.</div><div><br class=""></div><div>P. </div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sep 10, 2018 10:58 AM, Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" class="">pramsey@cleverelephant.ca</a>> wrote:<br type="attribution" class=""><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">I’m running parallel tests against v11 today, and finding things mostly unchanged from v10 with the exception of proper handling of target lists now. In general the low costing on PostGIS functions means that mostly parallelism doesn’t kick in even when we probably want it. Even our low cost C functions are still probably costed 10x too small.<div class=""><br class=""></div><div class="">In order to safely cost our functions, we have to first get a patch into PgSQL so that our inlining behaviour doesn’t get screwed up.  See the “What, Still Broken?” section of [1] for information on that.</div><div class=""><br class=""></div><div class="">However, in anticipation of that Wondrous Day and to aid in easier testing for folks who do patch their PostGIS, I’d like to bring costing into postgis.sql.in with some new macros, to replace the current inline costing. We can then set the macros to suitably low values to avoid having failures of our inlined functions.</div><div class=""><br class=""></div><div class="">The change would look like this one being used at Carto [2]</div><div class=""><br class=""></div><div class="">Thoughts?</div><div class=""><br class=""></div><div class="">P</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[1] <a href="https://carto.com/blog/inside/postgres-parallel/" class="">https://carto.com/blog/inside/postgres-parallel/</a></div><div class="">[2] <a href="https://github.com/CartoDB/postgis/pull/7/commits/c0b23850d0b2b1447310e3459a814b0eea380f60" class="">https://github.com/CartoDB/postgis/pull/7/commits/c0b23850d0b2b1447310e3459a814b0eea380f60</a></div><div class=""><br class=""></div><div class=""><br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">postgis-devel mailing list<br class=""><a href="mailto:postgis-devel@lists.osgeo.org" class="">postgis-devel@lists.osgeo.org</a><br class="">https://lists.osgeo.org/mailman/listinfo/postgis-devel</div></blockquote></div><br class=""></body></html>