Parallel queries and partitioning

One of the benefits of partitioning is the ability to parallelize spatial queries. If the query window spans multiple partitions (as is likely to happen with DATE based partitioning), then each partition can be queried in parallel. But the default behavior of partitioned spatial queries is not suitable for queries that span a large number of partitions on systems that have a large number of processors available for the queries. When a spatial query is issued against a partitioned spatial table and no partition key is used in the Where clause, then the spatial internally rewrites the query so that only those partitions that can potentially interact with the given window geometry are used. This is done by doing the spatial pruning query internally to find the list of partitions that can potentially interact with the window geometry, and this list of partitions is added to the Where clause. So, the user query is transformed to a query with additional predicates...