SQL Server Express Performance Limitations With OGC Methods on Geometry Instances

Question

I will front load my question.  Specifically, I am wondering if any of the feature restrictions with SQL Server Express cause performance limitations/reductions with OGC methods on geometry instances, e.g., STIntersects?  I have spent time reading
various documents about the different editions of SQL Server, including the Features Supported by the Editions of SQL Server 2014, but nothing is jumping out at me.  The
limited information on spatial features in the aforementioned document implies spatial is the same across all editions.  I am hoping this is wrong.
The situation....  I have roughly 200,000 tax parcels within 175 taxing districts.  As part of a consistency check between what is stored in tax records for taxing district and what is identified spatially, I set up a basic point-in-polygon query
to identify the taxing district spatially and then count the number of parcels within in taxing district.  Surprisingly, the query took 66 minutes to run.  As I pointed out, this is being run on a test machine with SQL Server Express.
Some specifics....  I wrote the query a few different ways and compared the execution plans, and the optimizer always choose the same plan, which is good I guess since it means it is doing its job.  The execution plans show a 'Clustered Index Seek
(Spatial)' being used and only costing 1%.  Coming in at 75% cost is a Filter, which appears to be connected to the STIntersects predicate.  I brute forced alternate execution plans using HINTS, but they only turned out worse, which I guess is also
good since it means the optimizer did choose a good plan.  I experimented some with changing the spatial index parameters, but the impact of the options I tried was never that much.  I ended up going with "Geometry Auto Grid" with 16 cells
per object.
So, why do I think 66 minutes is excessive?  The reason is that I loaded the same data sets into PostgreSQL/PostGIS, used a default spatial index, and the same query ran in 5 minutes.  Same machine, same data, SQL Server Express is 13x slower than
PostgreSQL.  That is why I think 66 minutes is excessive.
Our organization is mostly an Oracle and SQL Server shop.  Since more of my background and experience are with MS databases, I prefer to work with SQL Server.  I really do want to understand what is happening here.  Is there something I can
do different to get more performance out of SQL Server?  Does spatial run slower on Express versus Standard or Enterprise?  Given I did so little tuning in PostgreSQL, I still can't understand the results I am seeing.
I may or may not be able to strip the data down enough to be able to send it to someone.

Answer 1

Tessalating the polygons (tax districts) is the answer!
Since my use of SQL Server Express was brought up as possibly contributing to the slow runtime, the first thing I did was download an evaluation version of Enterprise Edition.  The runtime on Enterprise Edition dropped from 66 minutes to 57.5 minutes.
 A reduction of 13% isn't anything to scoff at, but total runtime was still 11x longer than in PostgreSQL.  Although Enterprise Edition had 4 cores available to it, it never really spun up more than 1 when executing the query, so it doesn't seem
to have been parallelizing the query much, if at all.
You asked about polygon complexity.  Overall, a majority are fairly simple but there are some complex ones with one really complex polygon.  Using the complexity index discussed in the reference thread, the tax districts had an average complexity
of 4.6 and a median of 2.7.  One polygon had a complexity index of 120, which was skewing the average, as well as increasing the runtime I suspect.  Below is a complexity index breakdown:
Index
NUM_TAX_DIST
1
6
<2
49
<3
44
<4
23
<5
11
<6
9
<7
9
<8
4
<9
1
<10
4
>=10
14
Before trying tessellation, I tweaked the spatial indexes in several different ways, but the runtimes never changed by more than a minute or two.  I reset the spatial indexes to "geometry auto grid @ 32" and tried out your tessellation functions
using the default of 5000 vertices.  Total runtime 2.3 minutes, a 96% reduction and twice as fast as PostgresSQL!  Now that is more what I was expecting before i started.
I tried using different thresholds, 3,000 and 10,000 vertices but the runtimes were slightly slower, 3.5 and 3.3 minutes respectively.  A threshold of 5000 definitely seems to be a sweet spot for the dataset I am using.  As the thread you referenced
discussed, SQL Server spatial functions like STIntersect appear to be sensitive to the number of vertices of polygons.
After reading your comment, it reminded me of some discussions with Esri staff about ArcGIS doing the same thing in certain circumstances, but I didn't go as far as thinking to apply it here.  So, thanks for the suggestion and code from another post.
 Once I realized the SRID was hard coded to 0 in tvf_QuarterPolygon, I was able to update the code to set it to the same as the input shape, and then everything came together nicely.