Hi Thomas - you're right to think about potential performance issues. As you've probably seen, content from all queues exists together in one (oftern very large) table, and so running processes will be accessing this table often. If you were to execute a 'heavy' query on this table it could drain the DB resources and affect the processes. The MI tables were introduced relatively recently to harvest MI into separate tables, away from the day-to-day queue activity. In general we don't advocate querying the DB directly, for performance and security reasons, but also because of the risk of inadvertently damaging something. As a minimum I would say don't run such a query when robots are working, do it in a downtime period, maybe at night?Another option that some take is to push data from the queue into a separate MI DB, so that MI queries can be run separately from the Prod BP DB. Again, such data harvesting could be done in bulk during quiet periods or, as some do, by the robots themselves when the work each queue item.Regarding queue data longevity, items will stay forever unless you remove them. This can be done manually from control room, or you can create a simple process to delete aged items. As with logs, managing queue growth needs to addressed as an ongoing housekeeping activity to keep the DB healthy.
