(I suppose the SQL part of my app is not the problem though, rather the number crunching that happens on the data returned. I do lots of caching on the results instead to make the site seem responsive.)
The first is that "oh my god" moment when you see via DDT that your view is doing 100+ queries to the database. This leads to research into Django ORM features like "select_related" and other ways to cut down the number of queries.
The second is clicking DDT's handy EXPLAIN button on a single query that is taking a long time. Sometimes this can help improve performance by adding an index to a field.
I'm not certain postgres for example has that kind of functionality around dates. Googling, I found this though:
http://justatheory.com/computers/databases/postgresql/recurring_events.html
If you just needed the events for today you should be able to do something simpler. Depends on the complexity of the frequency controls. But imagine weekly recurring - you should be able to do something like "(today - start day) mod 7 == 0" to find all weekly events that hit today. You could then construct a similar rule for each different frequency:
-- not real code!
select * from event where
(frequency = 'daily')
or (frequency = 'weekly' and (today - starts) % 7 == 0)
or (frequency = 'monthly' and day(today) == day(starts))
or (frequency = ...)