Yeah, I can believe that. That’s another trick about indexes… it’s really quite important that they’re constructed based on how they’ll be used.
With a historical table, the most common query is “where t_stamp>x” or “t_stamp>x and t_stamp<y”. Having the t_stamp column indexed as part of a multi-column index probably won’t help, since you’re not using those other columns in the query. This is a huge misconception about multi-column indices that people often make. They think that they can just throw any column they might want to query on into a single index and get some benefit. The exact result is dependent on the database (and in fact the data engine, in a situation like mysql that supports multiple), but it generally will not be helpful- and in fact could hurt- if you’re not querying on all of the columns together (all columns in the where clause).
So, creating a single index on t_stamp in your case was a good idea. As for clustering- a clustered index dictates how data is stored. For a historical table like this where you’re querying ranges of dates on the t_stamp, it makes a lot of sense to store that similar data close together. Of course, practically speaking your ndx column should have lined up pretty well with the order of your timestamps (because the data is likely being inserted in order), but there may be some subtleties of how the db can optimize on the fact that you’re filtering based on the actual column that’s clustered.