I was reading through docs and encountered this part:
| Consistency Level | Quorum Reads | Quorum Writes |
|---|---|---|
| Strong | Local Minority | Global Majority |
| Bounded Staleness | Local Minority | Local Majority |
| Session | Single Replica (using session token) | Local Majority |
| Consistent Prefix | Single Replica | Local Majority |
| Eventual | Single Replica | Local Majority |
So let's say I have Strong consistency set as default (for writes).
And I want to override it for some queries.
It would matter only if I select between Strong, Session and Eventual consistencies, because these are the ones with distinct Quorum Reads.
Changing between Strong and Bounded Staleness or Consistent Prefix and Eventual wouldn't matter, because it's only for reads - writes are still configured with Strong consistency.
Am I correct?
Edit: Though the sheer answer of @Mark doesn't satisfy me, it's complete for me with the comments, so I'm marking it as a solution.
To simplify, the answer is that effectively there's actually only 2 options in query relaxation: Strong and Consistent Prefix.
Relaxing the consistency level on reads, including queries does have an impact but that impact is one of cost. Strong and Bounded Staleness are Local Minority. This means reads are done on two replicas and the LSN's are compared between them. If they match the data is consistent. If they do not match, the item with the greater LSN is returned as it is the most recent write.
Because data is read from two replicas, the RU/s cost is 2x that of reads from Session or weaker consistency.
It is precisely because of this reduced cost that users may want to weaken their consistency on reads. If you're building an app that does not require perfect consistency and the data can lag by a small amount of time, this is perfectly suitable and less expensive way to do it. Particularly if the queries are done with high concurrency.
It's worth pointing out that relaxing the consistency level to session will result in Consistent Prefix being used. Session consistency requires the session token which today is only scoped to a single partition key range id. Since queries can span multiple partition key range values your effective consistency level used is essentially consistent prefix.