Determining when a table is "too big" or has too many indexes -- advice?

Good day, everyone!

Per Rob Burbank, PLEASE RESPOND TO THIS QUESTION ONLY IN THE DATA DICTIONARY FORUM [HERE!|determining-when-a-table-is-too-big-or-has-too-man]

I'm an ABAP programmer (6 years now) and am trying to get better at performance tuning and writing more efficient code. Recently, we had a report that started timing out in the foreground (after 10 minutes), and it's a read on the GMIA table.

I'm running into a wall trying to make the SELECT as efficient as possible, but I'm also wondering if I'm in a potential no-win situation based on the table's size and the number of indexes that have been built on it. In our Production system, there are 50,214,703 records in this table. On top of the 6 SAP-provided indexes on the table, another 7 custom indexes have been built in-house for a total of 13 indexes.

My question is this: As an ABAP programmer, how or what can I do in looking at a table's size and indexes -- or perhaps other aspects I don't know about -- to know that perhaps we've got bigger issues going on than just trying to make a SELECT statement more efficient? I'm just not versed enough on the database side to know how many records in a table or the number of table indexes is starting to push it. I also realize that there's probably no cut-and-dried answer here, as many things in SAP just aren't black or white. But somewhere in the shades of grey, there's got to be things I can do or learn in this area to help me.

As always, any advice is GREATLY appreciated. Thank you so much, and have a great weekend!