Sentry has brought an N+1 query to our attention. An N+1 query describes a situation in which you fetch data from the DB, then for each entry you fetch more data from the DB, and so on, until you're hitting the DB with a gazillion queries.
Normally we're not super strict about optimization but considering that this is one of our few public-facing pages we should at least not have it be a potential DOS target.
What (I think) is happening with the public archive is that we're getting a QS of all public proposals, and then in the template we're hitting the database with proposal.reviewing_committee.name for every single item. Because reviewing_committee.name traverses a ForeignKey relationship into the Groups DB this becomes an expensive N+1 query situation.
This can be resolved by annotating the proposals QS with the relevant data in the view, or using select_related().
Sentry has brought an N+1 query to our attention. An N+1 query describes a situation in which you fetch data from the DB, then for each entry you fetch more data from the DB, and so on, until you're hitting the DB with a gazillion queries.
Normally we're not super strict about optimization but considering that this is one of our few public-facing pages we should at least not have it be a potential DOS target.
What (I think) is happening with the public archive is that we're getting a QS of all public proposals, and then in the template we're hitting the database with
proposal.reviewing_committee.namefor every single item. Becausereviewing_committee.nametraverses a ForeignKey relationship into the Groups DB this becomes an expensive N+1 query situation.This can be resolved by annotating the proposals QS with the relevant data in the view, or using
select_related().