CODEWITHSUNDEEP
oracle-databaseindexing
Sean Nguyen
Sean Nguyen

Reputation: 13158

what is the performance impact on oracle index on float column?

I have a column defined as Number (10,3) and this column is indexed. I was wondering if I convert this column to be an integer, will the index perform better on it. I will have to multiple by 10^7 and do a divide by 10^7 in my code for it. But i don't know if it is necessary?

Thanks,

Upvotes: 2

Views: 1442

Answers (1)

Justin Cave
Justin Cave

Reputation: 231741

It's almost certainly not going to be an appreciable difference.

The index may be slightly more compact because the integer representations may be slightly smaller than the fixed point representation. For example, the number 1234 requires 3 bytes of storage while the number 1.234 requires 4 bytes of storage. Occasionally, the reverse will be true and the fixed point value will require less storage, but it's 100 times more likely that the integer representation will be smaller than the reverse. You can see that yourself by populating a table with the first 1 million integers and the first million integers divided by 1000.

SQL> create table int_test( int_col number(38,0), fixed_col number(10,3) );

Table created.

SQL> insert into int_test
  2    select level, level/1000
  3      from dual
  4   connect by level <= 1000000;

1000000 rows created.

SQL> select sum(vsize(int_col)) int_col_total_size,
  2         sum(vsize(fixed_col)) fixed_col_total_size
  3    from int_test;

INT_COL_TOTAL_SIZE FIXED_COL_TOTAL_SIZE
------------------ --------------------
           3979802              4797983

SQL> ed
Wrote file afiedt.buf

  1  select count(*) int_larger_than_fixed
  2    from int_test
  3*  where vsize(int_col) > vsize(fixed_col)
SQL> /

INT_LARGER_THAN_FIXED
---------------------
                 8262

SQL> ed
Wrote file afiedt.buf

  1  select count(*) fixed_larger_than_int
  2    from int_test
  3*  where vsize(int_col) < vsize(fixed_col)
SQL> /

FIXED_LARGER_THAN_INT
---------------------
               826443

While the index is going to be slighly more compact, that would only come into play if you're doing some extensive range scans or fast full scans on the index structure. It is very unlikely that there would be fewer levels in the index on the integer values so single-row lookups would require just as much I/O. And it is pretty rare that you'd want to do large scale range scans on an index. The fact that the data is more compact may also tend to increase contention on certain blocks.

My guess, therefore, is that the index would use slightly less space on disk but that you'd be hard-pressed to notice a performance difference. And if you're doing additional multiplications and divisions every time, the extra CPU that will consume is likely to cancel whatever marginal I/O benefit you might get. If your application happens to do a lot more index fast full scans than the average, you might see some reduced I/O.

Upvotes: 6

Related Questions