Comments on: Discarding the Output of a Select Statement

By: Log Buffer #91: a Carnival of the Vanities for DBAs

Log Buffer #91: a Carnival of the Vanities for DBAs — Fri, 04 Apr 2008 16:51:21 +0000

[...] Aldridge, the Oracle Sponge, looks into discarding the output of a select statement: “. . . you want to run a select for a big bunch of rows, maybe for measuring [...]

By: Alex Gorbachev

Alex Gorbachev — Thu, 03 Apr 2008 23:30:12 +0000

Btw, Jonathan Lewis has done few interesting posts on similar topic (but not exactly with the same purpose in mind) and there is another hint he was talking about - NO_MERGE.

By: Brian Tkatch

Brian Tkatch — Thu, 03 Apr 2008 14:49:19 +0000

Very interesting thread and results.

Thanx David.

By: David Aldridge

David Aldridge — Wed, 02 Apr 2008 23:12:07 +0000

Hmmm, is that hint valid in the context of an in-line view? It produces a different execution plan to the subquery factoring alternative and is the same as if it weren’t there …

explain plan for select count(*) from (select /*+ materialize */ * from s_order);
select * from table(dbms_xplan.display);

explain plan for select count(*) from (select * from s_order);
select * from table(dbms_xplan.display);

explain plan for
with rowset as(select /*+ materialize */ * from s_order)
select count(*) from rowset;

select * from table(dbms_xplan.display);

These give me:

———————————————————————-
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
———————————————————————-
| 0 | SELECT STATEMENT | | 1 | 443K (1)| 02:13:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| S_ORDER | 11M| 443K (1)| 02:13:01 |
———————————————————————-

and

———————————————————————————————————-
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
———————————————————————————————————-
| 0 | SELECT STATEMENT | | 1 | | 532K (2)| 02:39:50 |
| 1 | TEMP TABLE TRANSFORMATION | | | | | |
| 2 | LOAD AS SELECT | | | | | |
| 3 | TABLE ACCESS FULL | S_ORDER | 11M| 5052M| 446K (1)| 02:13:56 |
| 4 | SORT AGGREGATE | | 1 | | | |
| 5 | VIEW | | 11M| | 86334 (4)| 00:25:55 |
| 6 | TABLE ACCESS FULL | SYS_TEMP_0FD9D6600_36AEF106 | 11M| 5052M| 86334 (4)| 00:25:55 |
———————————————————————————————————-

It’s interesting that the cost of the full table scan varies there between 443K and 446K. I wonder why?

By: Alex Gorbachev

Alex Gorbachev — Wed, 02 Apr 2008 22:38:00 +0000

What about:
select count(*) from (select /*+ materialize */ * from s_order where ...);

By: David Aldridge

David Aldridge — Wed, 02 Apr 2008 19:41:42 +0000

I think the first_rows issue is to be expected. Oracle probably overrides first_rows with all_rows when performing an insert. Something to bear in mind.

The change I usually see when people use a count(*) is that Oracle naturaly gets more index-happy. The count(*) can often be satisfied from an index, whereas the projecting the contents of columns is more likely to require table access.

By: Gabe

Gabe — Wed, 02 Apr 2008 17:19:19 +0000

I think there is the same side effect with the INSERT ALL method as with the COUNT(*) one.

I tested in a 10.1 instance.
First run: execute the following as is
Second run: uncomment the optimizer_mode statement.

My observations:
With the default optimizer_mode setting, the INSERT ALL did what my target statement naturally wanted to do; the COUNT(*) did not.
With the optimizer_mode set to first_rows, the INSERT ALL did not what the target statement naturally wanted to do; the COUNT(*) did.

create table t as select object_id a, object_name b, object_type c from all_objects; create index c on t (c); insert into t select * from t order by dbms_random.random; insert into t select * from t order by dbms_random.random; insert into t select * from t order by dbms_random.random; exec dbms_stats.gather_table_stats(user,'T',cascade=>true)


-- just to show the clustering factor stays roughly the same

select blevel, leaf_blocks, distinct_keys

      ,avg_leaf_blocks_per_key,avg_data_blocks_per_key

      ,clustering_factor,num_rows

from user_indexes where index_name='C';
-- uncomment this on the second run

--alter session set optimizer_mode=first_rows;
-- this is the target statement

explain plan for select * from t where c='SYNONYM';

select * from table(dbms_xplan.display());
explain plan for select /*+ first_rows */ * from t where c='SYNONYM';

select * from table(dbms_xplan.display());
explain plan for insert all when 1=0 then into t select * from t where c='SYNONYM';

select * from table(dbms_xplan.display());
explain plan for select count(*) from ( select * from t where c='SYNONYM' );

select * from table(dbms_xplan.display());

drop table t purge;

By: David Aldridge

David Aldridge — Wed, 02 Apr 2008 15:15:47 +0000

I think that in Richard’s case that choice was dictated by needing to run several thousands of select statements, but the principle stil works the same I suppose. You’d have to do some bulk collect thing … that might be too much like hard work for me.

By: Brian Tkatch

Brian Tkatch — Wed, 02 Apr 2008 15:07:54 +0000

Cute.

Personally, i test by shrinking the SQL*Plus window. Yes, yes, i know.

If i really cared, wouldn’t a PL/SQL routine be best? Just put the returns into variables and throw it away. (That’s what Richard did in his example here http://richardfoote.wordpress.com/2008/03/31/larger-block-index-tablespace-and-small-index-scans-performance-improvement-let-down/)