Today Q Apply stores detailed performance statistics on queue level. This idea raises the request to store certain Q Apply throuput statistics (like rows_processed) on subscription level. Background: Today it is very difficult / sometime impossible to identify the root cause in case Q Apply is overwelmed with workload and in case Q Apply cannot guarantee the required latency. In these situations we would like to know which tables are effected (to take correctve action on the source). The performance details we ask for could for example list the x heaviest hitters (e.g., the 10 subscriptions with the most workload). Ideally this information would be stored in a statistics table periodically or at least be written to a log file for investigation.
NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "firstname.lastname@example.org" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions