When there is a reorganization, lines change places - hence, rid' change - hence, indexes should become invalid. I doubt that any other DBMS would consult better.
The very first question therefore - whether it is valid such frequent reorganization of such big table it is necessary. I suspect that was not present. Perhaps, once a year is enough. Or even it is too frequent.
To change structure that it was possible to carry out reorganization in parts. To lead (if it is accessible).
Exists and " for poor": to break the table on some, assigning on them constraint's on which the line gets precisely to one, and to unite with view through union all.
That is instead of table t to create
create table t1 (... constraint c1 check...)
create table t2 (... constraint c2 check...)
create table tn (... constraint cN check...)
create view t as
select * from t1
select * from tn.
And at insertion attempt insert into t... Lines
All constraints c1... cn, except one, should give false
(By the way, not all know that, unlike where where lines for which the predicate gives undefined are not selected, the DBMS allows to interpose a line if the result of a predicate in check appeared undefined).
To add it is a lot of RAM, to pass from winchesters on .
To replace a software, to find at what developers more made.