RE: Optimizing a Simple 'select count(*)'
- From: Jonathan Lewis <jonathan@xxxxxxxxxxxxxxxxxx>
- To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Sun, 9 Mar 2014 15:25:00 +0000
Even without seeing the code, but assuming there is an index that includes the
required data column referenced in the predicate, it does seem a little odd
that Oracle has chosen a full tablescan rather than (worst case) an index fast
full scan.
The only obvious reason I can think of for this choice is that either the index
has grown to a much larger size than it should be, or the only available index
includes so many of the table columns that it actually HAS to be larger than
the table.
select blocks from user_tables where table_name = ...
select leaf_blocks from user_indexes where index_name = ...
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
@jloracle
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] on behalf
of Jared Still [jkstill@xxxxxxxxx]
Sent: 09 March 2014 13:14
To: fmhabash@xxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Optimizing a Simple 'select count(*)'
On Wed, Mar 5, 2014 at 11:56 AM, Fred Habash
<fmhabash@xxxxxxxxx<mailto:fmhabash@xxxxxxxxx>> wrote:
So, why should we live with such costly resource consumptions for such a simple
query?
We don't know enough about the tables and/or indexes.
If you include complete code for a reproducible test case, you will likely get
more response.
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Sr Oracle DBA at Pythian
Pythian Blog http://www.pythian.com/blog/author/still/
Oracle Blog: http://jkstill.blogspot.com
Home Page: http://jaredstill.com
Other related posts:
