* Developers on the team value their sanity and timebox chunks of time for deep focus work, leaving only parts of the day for reviews. Some developers may even take vacations or go to talk to customers, leaving a small team with less review bandwidth.
I don't know that it is optimal, but our team generally batches PRs once per day, to avoid interrupting them. So typically it's going to take about a half day for a review. As different people end their day at different times.
Exceptions of course, but this seems close to optimal to me (from the reviewers perspective).
If reviewing is the bottleneck for your team then having some slack where people sit around waiting to do reviews may well be the most efficient use of time (e.g. having a reviewer rotation where each week one person is a designated reviewer).
Waiting for more than 20-30 minutes for a review is ridiculous and means some combination of three problems are present:
* commits are too big to be reviewed quickly
* Tooling/testing is not catching a lot of blatant problems before the pull request happens.
* Review process has turned into some bizarre management ritual