Comment 3 for bug 723999

> I'm fairly sure this comes from code in
> lp.bugs.model.structuralsubscription.BugFilterSetBuilder.

Yes :)

> To satisfy my own curiosity, some small hand-made stats about the
> long queries.
>
> - There are four verrrry similar long queries, each taking between 1
> and 1.5 seconds. They may (hopefully) differ in the variables they
> use when they are called. I wouldn't be surprised if the four are
> looking at different duped bugs.

They may well be identical queries. Fixing this was part of the point
of my work on BugSubscriptionInfo.

> - Each unions query unions three distinct select statements, each of
> which is repeated several times. In the first long query, for
> instance, the first and second are *each* repeated (unioned) five
> times; the last is repeated four times. Other long queries
> apparently vary this somewhat (the second has five, five, and
> one), but the three unioned queries are identical across all four
> long queries.

Here's my analysis of just the first query in that OOPS:

- The "three distinct selects" look for subscription filter matches
  against each of status, importance and tags.

- The subscription ID is pulled from the intersection of these
  queries, and is UNIONed with all subscriptions without filter.

- The full structural subscription rows are materialized from these
  IDs.

- *14* of these queries are UNIONed together:

  - The last 4 are looking for distroseries subscriptions (and any
    associated filters). I'm not sure why there are 4, and not say 5,
    of these, but BugTaskSet._getStructuralSubscriptionTargets()
    probably will explain more.

  - Of the remaining 10, 5 are for source package subscriptions, one
    for each bugtask.

  - The other 5 are looking for subscriptions on the distribution, one
    for each bugtask.

> As an aside, I was already wondering why we calculate any part of the
> recipients live at all (as opposed to waiting for the cron script),
> but I was hoping not to have to address that potential change as part
> of this story.

Like for you, I think it's there simply because it's more work to move
it. BugSubscriptionInfo is meant to make offlining this stuff easier,
because it's intended to be able to work with a bug snapshot too,
rather than requiring a "live" bug in the correct state.