[postgis-devel] Costing 3.0 Functions

[Paul Ramsey]

> On Sep 10, 2018, at 11:15 AM, Paul Norman <penorman at mac.com> wrote:
> 
> 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.

It’s a little subtle to trigger, but it definitely happens for both our functions and for built-ins.

https://www.postgresql.org/message-id/CACowWR2kuB_yApPhB%3DzUQ_rKqN5NpdAvNfQqYZ0PhRPBVCbz6g%40mail.gmail.com <https://www.postgresql.org/message-id/CACowWR2kuB_yApPhB=zUQ_rKqN5NpdAvNfQqYZ0PhRPBVCbz6g@mail.gmail.com>


> Do we have a list of what functions still need accurate costs?

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 http://blog.cleverelephant.ca/2017/10/parallel-postgis-2.html <http://blog.cleverelephant.ca/2017/10/parallel-postgis-2.html> 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.

P. 


> 
> On Sep 10, 2018 10:58 AM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 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.
> 
> 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.
> 
> 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.
> 
> The change would look like this one being used at Carto [2]
> 
> Thoughts?
> 
> P
> 
> 
> [1] https://carto.com/blog/inside/postgres-parallel/ <https://carto.com/blog/inside/postgres-parallel/>
> [2] https://github.com/CartoDB/postgis/pull/7/commits/c0b23850d0b2b1447310e3459a814b0eea380f60 <https://github.com/CartoDB/postgis/pull/7/commits/c0b23850d0b2b1447310e3459a814b0eea380f60>
> 
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180910/e3c31931/attachment.html>