If you were to rebuild the entire index on BigTable using an OFFLINE (default) rebuild, the entire table would be offline for querying for the duration of the rebuild. You also have the option of rebuilding the entire index using an ONLINE rebuild, which would keep the entire table query-able (both read and write) for the nearly the entire duration (there are 2 relatively short phases at the beginning and end of the operation that are not entirely online) of the rebuild (with some other potential side-effects such as using more disk space, taking longer, etc.). For more information on Online index operations, see how they work and guidelines for performing them.
If you want to rebuild just a single partition of the BigTable, you have very similar options as with the entire table, however the concurrency impact is restricted to the partition you are rebuilding. There are limitations to single-partition rebuilds, such as the fact that you can't perform a single partition rebuild ONLINE (i.e. if you decide to rebuild a single partition, you must do so OFFLINE, which means the data for the given partition will be inaccessible for the duration of the rebuild). For details on options here, see the single-partition options in the ALTER INDEX statement documentation.
As for specifically answering when/how the Sql engine determines what portions of a given index (partitioned or not) should be rebuilt/accessed during a rebuild operation, it really doesn't matter - the options you have in terms of concurrency are:
- Rebuild the entire index (or all partitions)
- Rebuild a single partition
If you specify the entire index/all partitions, you'll wind up with the concurrency semantics outlined in the first paragraph above. If you specify a single partition, the concurrency semantics would be as outlined in the second paragraph.