Add note to 'Choose a partition key' section.

In my opinion, I think this section may be a bit miss leading for users without enough data to have multiple physical partitions. With a single partition, all queries will scan the full physical partition, which means that the partition key/logical partition will not help them to get better RU consumption. In fact, with a single physical partition, adding the partition key to the query will result in higher RU consumption. 

Not sure if I was clear enough in my note, feel free to change it.

Author: soferreira

articles/cosmos-db/partitioning-overview.md

@@ -102,6 +102,9 @@ For **all** containers, your partition key should:
 
 If you need [multi-item ACID transactions](database-transactions-optimistic-concurrency.md#multi-item-transactions) in Azure Cosmos DB, you will need to use [stored procedures or triggers](how-to-write-stored-procedures-triggers-udfs.md#stored-procedures). All JavaScript-based stored procedures and triggers are scoped to a single logical partition.
 
+> [!NOTE]
+> In case you only have one physical partition, partition key may not be relevant as all queries will hit the same physical partition. 
+
 ## Partition keys for read-heavy containers
 
 For most containers, the above criteria is all you need to consider when picking a partition key. For large read-heavy containers, however, you might want to choose a partition key that appears frequently as a filter in your queries. Queries can be [efficiently routed to only the relevant physical partitions](how-to-query-container.md#in-partition-query) by including the partition key in the filter predicate.