Is it permissable to extend an SAP-provided table index?

Question

(Please note I realize this might not be the best forum for this post; I did look at ABAP development, SAP on Oracle, and a few others, but given some other threads, it seemed like this might be the best place for it.  Apologies if not).
We have a very large table (GMIA), and I noticed that two customer-created indexes can essentially be combined into one because the first index is RGRANT_NBR plus fields A and B, and the second index is RGRANT_NBR plus fields A, B, C, D, and E.  So I might as well get rid of the first index and just keep the second one having RGRANT_NBR plus fields A through E.
However, I noticed that SAP-provided index 4 contains simply one field - RGRANT_NBR.  So ideally, I could just add fields A, B, C, D, and E to index 4, then I could get rid of my second customer-created index.
Question:  Is it permissable to extend an SAP-provided index like this?  As a developer, I'm not in the modifying SAP objects business, but this is the first time I've been presented this situation with a table index.  Given that our GMIA table has MILLIONS of records in it, getting rid of another customer-created index completely might be a great opportunity.
Thoughts?
Dave

Answer 1

I really don't have a requirement for this.  I'm a developer, and I've noticed some of our biggest timeout issues concern programs that hit table GMIA.  So I thought I'd take a look at GMIA and our indexes to learn more about it via SE11 and DB02.
In our Production environment, we have over 88 million records in this table for a table size of 38.23 GB.  Aside from the 6 SAP-provided indexes, 8 customer indexes have been created by others over time.  It was in looking at these indexes that I noticed our 8th customer index, ZS8, is essentially the same 3 fields as ZS3, plus a few more fields.  Ideally, ZS8 should NOT have been created, and ZS3 should have simply been extended with the additional fields.
It was suggested to me in another thread a long while back that I could potentially get rid of ZS3 as well and just make SAP index 4 look like ZS8 because SAP index 4 is just indexed by Grant Number (RGRANT_NBR).  ZS8's first index field is Grant Number followed by 5 or 6 additional fields.  That's why I was wondering if it was even a "thing" or a possibility to extend an SAP index, but customizing an SAP component makes Dave a very, VERY nervous boy.
Basically, I'm alarmed at the number of records in the table and the number of indexes we have.  There's no archiving strategy here, so I probably can't do anything about the number of records in GMIA, which go back to 2006 when we first went live with SAP.  But I can clearly get rid of one customer-created index (ZS3).  And if I can deactivate SAP index 4, I would assume the system would then automatically use ZS8 since the first field is Grant Number for situations where it would have used SAP index 4.
So that's the background here.  Honestly, I don't know how much improvement these things will make, but getting rid of ZS3 will save 5 GB of space, and presumably "deactivating" SAP index 4 would save almost 5 GB as well.  I'm assuming we might see some negligible performance gains on our table operations involving GMIA, but it's still a beast with a large number of indexes, so I don't know.
I'm really, really interested in hearing from others' thoughts and recommendations -- your input is MOST welcome here!
Dave