What we are trying to do is to eliminate un-needed indexes. Ex. On one table, we have 10 indexes and we would like to drop indexes that are not being used or rarely used.

I can see how this would be useful; it's something that Gupta SQLBase used to have - a UseCount field in the sysindexes system table. We monitored it for indexes where the count wasn't increasing over a fairly long period and dropped them if they never got used.

However I imagine that there is considerable overhead to maintain such data, and it's noticeable that later versions of SQLBase don't support it.

If you have a lot of dynamic SQL, effective checking of plans for which indexes are selected for use is going to be tricky, and can change as the distribution of data changes. At the end of the day I think you are going to have to rely on your knowledge of your product and therefore they sort of queries that are going to be run, to decide what is likely to be useful.

There are two things in your favour though, SQL Anywhere automatically optimizes duplicate indexes and only maintains one physical version. Second, unless you have very high transaction throughput, the actual overhead of maintaining indexes seems to be pretty low, compared with everything else going on.