Any system parameter can do what "no_merge" do?

Question

We are trying to move the database to a new server and get performance hit. This is a simple query but with OWM we have more than 10 years historical data in LT tables.
1. With just ordered hint, it takes 6:30 mins to run
SELECT /*+ ordered*/  COUNT (a.id)
  FROM slimdba.neighbourhoods b,slimdba.zoning_polygons a
WHERE   b.id = 170
   AND sdo_relate (a.geometry, b.geometry,  'mask=INSIDE+COVEREDBY+EQUAL querytype=WINDOW' ) = 'TRUE';
2. With parallet hint, it takes 1:05 mins to run
SELECT  /*+ full(b) parallel(b,8) */ COUNT (a.id)
  FROM slimdba.neighbourhoods b,slimdba.zoning_polygons a
WHERE   b.id = 170
   AND sdo_relate (a.geometry, b.geometry,  'mask=INSIDE+COVEREDBY+EQUAL querytype=WINDOW' ) = 'TRUE';
3. With no_merge(b) hint, it only process the current live data in b, it takes only 4 seconds
SELECT  /*+ ordered no_merge(b) */ COUNT (a.id)
  FROM slimdba.neighbourhoods b,slimdba.zoning_polygons a
WHERE   b.id = 170
   AND sdo_relate (a.geometry, b.geometry,  'mask=INSIDE+COVEREDBY+EQUAL querytype=WINDOW' ) = 'TRUE';
In most of the cases our users only care about live data. Is there a system level setting to ask Oracle to filter the live data first instead of using LT table first then filter after the spatial process?
Thanks a lot for any help!!
Sharon

Answer 1

Hi Sharon,
I have previously seen this type of performance with spatial operators.  It is a result of the optimizer choosing to apply the spatial operator prior to determining the single row being seen from the neighbourhoods view.  In this example, there are most likely many rows with id=170 in the underlying _LT table, but only a single row will be ultimately seen from the slimdba.neighbourhoods view.  If the optimizer finds the single row prior to applying the spatial operator, then performance is very good.  If on the other hand, it finds all of the rows with id=170, applies the operator, and then filters that set to the one row being seen by the view, the performance has the tendency to be slow and it's directly proporational to the number of rows with id=170 in _LT.
We have seen good performance transforming the query into the following.  This typically will force the slimdba.neighbourhoods view to be fully materialized prior to applying the spatial operator.  However, it does require rewriting the query.
SQL> with n as (select /*+ materialize */ geometry from slimdba.neighbourhoods where id = 170)
         select count(id)
         from slimdba.zoning_polygons a, n b
         where sdo_relate (a.geometry, b.geometry,  'mask=INSIDE+COVEREDBY+EQUAL querytype=WINDOW' ) = 'TRUE';
Using the NO_MERGE hint as you have done, is also an option.  The important point is that the optimizer evaluates the version predicates(the view logic) prior to applying the spatial domain index.  Any additional hints, change in optimizer parameters that achieves this goal can be used.
If changing the query is not possible, and it was working as expected on the previous server then I would need to know additional information.  Has the RDBMS version changed in the process of switching servers or remained the same?  Are the statistics the same on both?  There isn't any Workspace Manager specific parameter that would cover this situation as the optimizer is ultimately responsible for the sql plan.  There is the capability to explicitly add a hint to the underlying view, but that is typically something that we do not recommend in this case as the hint would be there even for queries that it doesn't make sense for.
Regards,
Ben