Hash clusters are always created at full size based on the HASHKEYS and SIZE parameters. Thus the high-water mark immediately reflects the expected size of the segment, even before it contains any data. The high-water mark is only raised if block chaining becomes necessary, which should hopefully be rare. This means that, apart from block chaining, the full table scan cost of a hash clustered table is invariant on the number of rows in the table.

What you are seeing is the normal, expected behaviour. If the performance of this query is important, you should provide an index that the optimizer can use to satisfy the query instead of using a full table scan.

Hash clusters cannot be truncated. You would get ORA-03293 if you were to try.

I am new to hash clusters and we are bringing up an application that uses them. One of the consultants that is helping to implement this application is having a performance issue querying against a table in the hash cluster. The table is empty. The statement is:

SQL> set timing on
SQL> select count(1)
  2  from sysadm.rtx_lt_001;

  COUNT(1)
----------
         0

Elapsed: 00:00:53.85