Thanks for that – the impact of the HAVING clause is a detail I haven’t looked at for a very long time.
I suspect the effects are version dependent (when, for example) can the optimizer push the having clause arithmetic down into the WHERE clause arithmetic).

I’ve just done a couple of quick tests with a larger data set, and come up with two cases – one where the arithmetic is applied twice, and one where it’s applied once. (The predicate still appears twice in the execution plan output, though). I’ll have to write up the details some time.

set echo off timi off
drop table my_data_files purge;
create table my_data_files as 
select * from dba_data_files union all
select * from dba_data_files union all
select * from dba_data_files
;
-- exec dbms_stats.gather_table_stats(null,'my_data_files')
explain plan for
select 
	file_name, tablespace_name, sum(bytes)/(1024*1024*1024) 
from 
	my_data_files 
group by 
	file_name, tablespace_name
having 
      sum(bytes)/(1024*1024*1024) > 0 
  and sum(bytes)/(1024*1024*1024) > 0 
--  and sum(bytes)/power(1024,3) > 0
;

select * from table(dbms_xplan.display);

And the output:

11:51:59 dbread@pd12m>@predicates

Table dropped.


Table created.


Explained.


PLAN_TABLE_OUTPUT
----------------------------------
Plan hash value: 3621239192

-------------------------------------------------------------------------------------
| Id  | Operation           | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |               |    66 | 19008 |     4  (25)| 00:00:01 |
|*  1 |  FILTER             |               |       |       |            |          |
|   2 |   HASH GROUP BY     |               |    66 | 19008 |     4  (25)| 00:00:01 |
|   3 |    TABLE ACCESS FULL| MY_DATA_FILES |    66 | 19008 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter(SUM("BYTES")/1073741824>0 AND SUM("BYTES")/1073741824>0)

Note
-----
   - dynamic sampling used for this statement (level=2)

19 rows selected.

Hope this helps.

Do you have a couple of simple examples of duplicated preidcates surviving ? There have been various changes in the optimizer over the last few versions (10g onwards) to deal with different scenarios, but I hadn’t noticed any cases of duplicates surviving recently. Every version has to be checked in detail, of course, but as a general guideline (and ignoring predicates generated by RLS/FGAC in the very latest versions, I think) if a predicate appears twice it’s selectivity is applied twice.

Contrary to your observation, I actually have an example in 11.2.0.3 where I would like Oracle to keep a duplicated predicate because that would allow it to use a very efficient execution path that is otherwise not available.

1 – filter(SUM(“BYTES”)/1073741824>0 AND SUM(“BYTES”)/1073741824>0)

As a matter of fact, even exactly duplicated (before any transformation or pre-calculation) predicates survive. Must check whether they affect any cardinality estimates though.