Stefan,
That thought didn't cross my mind until too late. I'd be inclined to assume
that a very repetitive, "long" first column could take a lot of space in the
sort segment but end up taking much less in the index segment if compression
were used - I may have to test the "no compression in sort segment" hypothesis
later on today.
Greg,
Following up to the compression problem - if you do an "explain plan" on
"create index" it should tell you roughly how large the index would be
uncompressed - this might give you a better idea of the required workload than
the final size of the index would indicate. See:
https://jonathanlewis.wordpress.com/2009/05/22/index-size/
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
@jloracle
________________________________________
From: Stefan Koehler [contact@xxxxxxxx]
Sent: 04 July 2015 10:36
To: Jonathan Lewis; oracle-l@xxxxxxxxxxxxx; grzegorzof@xxxxxxxxxx
Subject: RE: Large index creation speed up / issues with direct path read temp
/ direct path write temp
Hi,
@Jonathan:
However the "real" data might be bigger than the 70 GB as GG is using index key
compression. AFAIK this is only done on index leaf
block level and not already done by sorting in some kind of way. Am i right or
are there enhancements as well?
--
//www.freelists.org/webpage/oracle-l
