My Oracle Support Banner

No Query Rewrite (QSM-01112) When SYSDATE Comparison in WHERE Clause (Doc ID 1364498.1)

Last updated on JANUARY 05, 2020

Applies to:

Oracle Database - Enterprise Edition - Version 8.1.7.4 to 11.2.0.3 [Release 8.1.7 to 11.2]
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Information in this document applies to any platform.

Symptoms

NOTE: In the images and/or the document content below, the user information and data used represents fictitious data from the Oracle sample schema(s) or Public Documentation delivered with an Oracle database product.  Any similarity to actual persons, living or dead, is purely coincidental and not intended in any manner.

A query would rewrite when an explicit to_date comparison was made in the where clause, but would not rewrite if the 'to_date' conversion was replaced by 'sysdate.'

Here is the materialized view (mview):

CREATE MATERIALIZED VIEW <MView_Name>
BUILD IMMEDIATE
REFRESH COMPLETE ON COMMIT
ENABLE QUERY REWRITE
AS
select
pk, dt
from
<Table_Name>
where dt >= to_date('01-JAN-2011 00:00:00','DD-MON-YYYY HH24:MI:SS');


This query rewrites:

query:
'select pk,dt from <Table_Name> where dt >= to_date(''01-JAN-2011'',''dd-mon-yyyy'')'

STATEMENT_ID SEQUENCE MESSAGE
------------------------------------------------------------------------------
--
------------------------------------------------------------------------------
--------------------------
20110816_T1 2
QSM-01033: query rewritten with materialized view, <MView_Name>


This query does not rewrite (note that SYSDATE had a value of '09-SEP-2011', which should be satisfied by the mview):

query:
'select pk, dt from <Table_Name> where dt >= sysdate';

STATEMENT_ID SEQUENCE MESSAGE
------------------------------------------------------------------------------
--
------------------------------------------------------------------------------
--------------------------
20110816_T2 2
QSM-01112: WHERE clause of mv, <MView_Name>, is more restrictive than query


Additionally, an explain plan of a simple select statement seems to show that value of SYSDATE is being evaluated, since the plan changes when the comparison operator changes:

=============================
No ROWS example (future records only)
select * from <Owner_Schema>.<Table_Name_2> where time_id > sysdate
=============================

Plan hash value: 2294783259
-----------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
-----------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 29 | 2 (0)| 00:00:01 | | |
| 1 | PARTITION RANGE ITERATOR | | 1 | 29 | 2 (0)| 00:00:01 | KEY | 28 |
| 2 | TABLE ACCESS BY LOCAL INDEX ROWID| <Table_Name_2> | 1 | 29 | 2 (0)| 00:00:01 | KEY | 28 |
| 3 | BITMAP CONVERSION TO ROWIDS | | | | | | | |
|* 4 | BITMAP INDEX RANGE SCAN | <Table_Name_2>_TIME_BIX | | | | | KEY | 28 |
---------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("TIME_ID">SYSDATE@!)
filter("TIME_ID">SYSDATE@!)


>>=============================
>>
Whole Table Example
>>
select * from <Owner_Schema>.<Table_Name_2> where time_id < sysdate
>>>
=============================
>>

>>Plan hash value: 279964487
>>
----------------------------------------------------
>>
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart|
>>> Pstop |
>> ----------------------------------------------------
>>
| 0 | SELECT STATEMENT | | 918K| 25M| 508 (5)| 00:00:07 | | |
>>
| 1 | PARTITION RANGE ITERATOR| | 918K| 25M| 508 (5)| 00:00:07 | 1 |
>> KEY |
>>
|* 2 | TABLE ACCESS FULL | <Table_Name_2> | 918K| 25M| 508 (5)| 00:00:07 | 1 |
>> KEY|

>>---------------------------------------------------

>>
>>Predicate Information (identified by operation id):
>>
---------------------------------------------------
>>
2 - filter("TIME_ID"<SYSDATE@!)>>


Question:
Therefore, shouldn't the value of SYSDATE in the query be evaluated when determining if the query will or will not rewrite?

Changes

 

Cause

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!


In this Document
Symptoms
Changes
Cause
Solution
References


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.