I found this query in my server log:
            select nnr.*
            from (select notifications.notification_id,
                    notifications.notif_subject,
                    notifications.notif_text,
                    notifications.notif_html,
                    notification_requests.user_id,
                    notification_requests.type_id,
                    notification_requests.delivery_method_id,
                    notification_requests.request_id,
                    notifications.response_id,
                    notifications.notif_date
                  from notifications, notification_requests
                  where notifications.type_id = notification_requests.type_id
                    and notifications.object_id = notification_requests.object_id
                    and notification_requests.interval_id = :interval_id) nnr,
              notification_user_map, acs_objects
            where nnr.notification_id = notification_user_map.notification_id(+)
              and nnr.user_id = notification_user_map.user_id(+)
              and notification_user_map.sent_date is null
              and acs_objects.object_id = nnr.request_id
              and acs_objects.creation_date <= nnr.notif_date
            order by nnr.user_id, nnr.type_id
It is the second-most expensive query on a loaded system.
Now what I find fairly fishy is that the join to notification_user_map is an outer join. Why is that so? If there is no user for the notification, I cannot send it all, right?
Why is that an issue? Here's the cost for the query with an outer join:
Statistics
----------------------------------------------------------
          0  recursive calls
         11  db block gets
    1296647  consistent gets
        654  physical reads
And here for an inner join:
Statistics
----------------------------------------------------------
          0  recursive calls
          7  db block gets
        774  consistent gets
          8  physical reads
Whopping!