CARTO users want to see maps drawn quickly, and drawing maps quickly means rendering every geometry in a table to an output format. By deploying the latest version of PostgreSQL to our infrastructure, we are taking advantage of improved parallel query support to make our maps and widgets go faster.
This would be the shortest blog post of all time except for one inconvenient fact: stock PostgreSQL 10 with stock PostGIS 2.4 doesn’t parallelize spatial queries very well at all.
In particular, for the kinds of routine calculations that CARTO runs, parallel processing doesn’t kick in:
- Parallel scans still require higher function costs to come into action, even in reasonable cases.
- Parallel joins on spatial conditions still seem to have poor planning, requiring a good deal of manual poking to get parallel plans.
To get the kind of parallel performance we wanted from PostgreSQL 10 + PostGIS 2.4 we had to tweak both packages a little bit.
For users of PostGIS, one of the big surprises (and disappointments) of stock parallel support in PostgreSQL 10 is that the planner only looks at the contents of the
WHERE clause when determining if a scan should be parallelized.
On the other hand, a query with even a very costly spatial function (like a buffer) on the
SELECT line (what PostgreSQL hackers call the “target list”) won’t get parallelized no matter how many rows are in play.
If I have a slow function which is evaluated in a simple seq scan, I do not get parallel execution, even though it would be massively useful. Unless force_parallel_mode=ON, then I get a dummy parallel plan with one worker.
– Jeff Janes, pgsql-hackers, 2017-07-11
The ensuing discussion led to a revised patch from Amit Kapila of EnterpriseDB that would generate parallel plans for queries that included costly functions in the target list.
While Amit has continued to revise his patch over the succeeding months, it has not been committed to the main PostgreSQL development tree yet, so there’s no guarantee that PostgreSQL parallel behaviour for costly functions on the target list will improve in version 11.
As a general proposition, the costs of PostGIS spatial functions are much much higher than the costs of ordinary functions in PostgreSQL. Even though all PostGIS functions are written in C, they still have to perform vastly more calculations to return a result than most standard PostgreSQL functions: computational geometry is complicated!
Prior to parallelism, the declared
COST of a function would rarely effect the query plan generated by PostgreSQL – no matter what plan was chosen, the function result had to be calculated.
With parallelism though, the decision about whether or not to set up a parallel plan is a function of number of rows to be processed times function cost. A higher function cost can flip a plan over from single-worker to parallel.
PostGIS has not globally applied costs to functions in the past, because the planner had no use for it, and it’s a lot of work – there’s hundreds of functions in PostGIS. Why spend all that effort to add costs that would never actually affect a plan?
However, with Amit’s patch we had a use for costs, so we added explicit costs to a number of high-cost spatial functions.
At this point, we had:
So, we should be done! But we weren’t.
A lot of very heavily used PostGIS functions are actually SQL wrappers that cover up more complex combinations of other functions. For example:
PostGIS expects that functions of this sort will be “inlined”. That PostgreSQL will, when finding one of these functions, replace the function with contents of the function definition. So:
Would be silently inlined as:
The trouble is that deep in the PostgreSQL code base is logic that determines if a given function can be inlined, and one of the things that determines whether inlining is allowed is if the functions being inlined are not too costly. And we just increased the costs of many of our functions.
The PostgreSQL inlining behaviour seems to be justified for users who use SQL wrapper functions as a way to force the caching of expensive calculations underneath the wrapper. That is never our use case at CARTO, so we don’t mind losing that behaviour in order to get back “sensible” inlining with our properly costed functions.
The problem of losing inlining behaviour was discussed on the pgsql-hackers list in November 2017, but no patch was offered, and our patch is not suitable for general application since it changes behaviours that some users might want to retain.
The simplest way to ape the CARTO installation is to just use our patched PostgreSQL and PostGIS forks:
If you want to roll your own, you can:
Please fill out the below form and we'll be in touch real soon.