What follows is an estimation, done by the Campaigns team, of the number of queries that could be expected for the tables added by the CampaignEvents extension. Note that these are overestimates, and we don't really expect these numbers, especially not immediately after the release.
==Monthly event data==
Based on data provided by @ifried, we estimate:
- 500 events per month
- 300 participants per event
- 5 organizers per event
==Cost of each operation that involves DB access==
This is the number of queries (on average) of each operation that can happen in the CampaignEvents extension. We may have forgotten something, but since these are overestimates, it shouldn't really matter.
-- Assuming that for each event, the organizer will remove 1+ users 5 times: events_per_month * 5 * 1 = 500 * 5 = 2500
- W: participant changes visibility
-- Assuming that 10% of participants will do it: events_per_month * participants_per_event * 1/10 * 1 = 300 * 500 / 10 = 15000
- W: organizer added
-- Assuming that it’ll happen 5 times per event: events_per_month * 5 * 1 = 500 * 5 = 2500
- W: organizer removed
-- Assuming that it’ll happen 5 times per event: events_per_month * 5 * 1 = 500 * 5 = 2500
- R: participant opens Special:EventDetails
-- Assuming that each participant will open the page 10 times (and the number of queries assumes that they’ll always stop after the initial batch): events_per_month * participants_per_event * 10 * 5 = 500 * 300 * 10 * 5 = 7500000
- R: organizer opens Special:EventDetails
-- Assuming that each organizer will open the page 20 times (and the number of queries assumes that they’ll always scroll to the bottom of the list of participants): events_per_month * organizers_per_event * 20 * (3 + num_part / 20) = 500 * 5 * 20 * ( 3 + 300 / 20 ) = 900000
- R: user opens Special:MyEvents and interacts with it
-- Assuming that users will open the page twice a day, i.e. 60 times per month, and each time they’ll “interact” (change page, change sorting, filter) 5 times with it. Also assuming that the number of people who have reasons to open that page is gonna be 2000. 2000 * 60 * 5 * 1 = 600000
- R: someone opens event page
-- Assuming each event page will be visited by three times the number of average participants to each event. Events_per_month * participants_per_event * 3 * 6 = 500 * 300 * 3 * 6 = 2700000
-- As above, assuming each event is modified once after creation, on average: events_per_month * 1 * 2 = 500 * 2 = 1000
- W+R: timezone script runs!
-- Assuming that we will set it to run daily, so 30 times per month. It scans the whole table though, so the cost increases each month. We can estimate the reads as events_per_month * months_elapsed / 500 = months_elapsed
==Queries per table==
This is the number of queries, as obtained in the previous section, but per-table rather than per-action. The reason why this wasn't done before is that at first I didn't realize the question was per-table.