Just a heads up, we've got what *looks* like a death-by-a-thousand cuts. Take +filebug with an apport UUID.
The attachments from apport are attached to the bug as part of the bug creation. Each attachment raises a notification; that is listened for and generates a mail notification insertion. So, a package with 50 subscribers and an apport attachment with 20 generates 1000 INSERTs into the system. Now, there is a storm feature request to group the inserts, but the flush before a select would almost certainly mean that we still end up doing 20 batch inserts (and its still 1000 rows). A better way to structure this is to raise a *single* event at the end of adding all attachments & creating the bug, which will generate 50 notification entries: still a lot, but nowhere near as bad. It may be, due to the contextual friction that we really don't want in-process events for this sort of thing at all : but that would be a very broad conclusion to draw, and I hesitate to do so. I am however convinced that we shouldn't be raising many events of any sort where nontrivial work (and db access is nontrivial) occurs as a result of raising it. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
