The important difference between create_table_cost and create_index_cost is that you supply the correct DDL for creating an index on an existing table to create_index_cost – and Oracle uses the table-related stats in the data dictionary to do its arithmetic – whereas you simply provide a list of column types and sizes (or just a row size) with some other numbers to use create_table_cost.

It shouldn’t be too difficult for Oracle to include a routine to take a DDL statement for ‘create table’ and do the same sort of thing. (In fact, I think I’ve seen one such routine but I can’t remember where). Of course, you could just take the top line output from dbms_xplan.display() for ‘explain for create table…’ and use the Rows and Bytes columns to work out the space requirement by hand.

But I am weary of any (space-, size-)esitmate.
Reality tends to invalidate any size-estimate by roughly a factor of 10 (pi-square rounded to a whole number) before the year is over.

Index-Compression (of suitable indexes) is an under-used feature and a bit of promotion for that would be good.

But for existing indexes,
what about the old-fashioned:

SQL> analyze index abc_pk VALIDATE STRUCTURE ;

Followed by a select from INDEX_STATS ?

(also a bit of work, as it needs to be done one-at-a-time, and I’m fairly lazy myself)

I think the EXPLAIN PLAN on CREATE INDEX functionality is really quite limited. It starts with the dependency on the available statistics, not considering the number of nulls defined for the column (at least for the “ROWS” shown, may be indirectly for the size by using the AVG_COL_LEN) and doesn’t end with no reasonable support for function-based indexes and their expressions (which is challenging I have to admit).

Not to mention the shortcomings you’ve pointed out: No compression considered and the “tablespace” oddity.

Some details about my findings in this regard: http://oracle-randolf.blogspot.com/2009/02/explain-plan-on-ddls.html

Regards,
Randolf