Rapid schedule query in IAM requires to much resources.

Hi, I’m currently running into performance problems caused by a scheduled system flow with a very rapid schedule (every second). This seems logical, we are running this code a lot so it stands to reason that it uses a lot of resources, except that the queries in our model executed by this flow, are extremely optimized. Our monitoring indicates that the query used by IAM to fetch the schedule for this flow in the stored procedure process_flow_schedule_start currently uses a ton of CPU time. So much so, that even with a slowed down schedule, it makes the top 3 most resource intensive queries run on the database server. 

User complained about a slow working application and we’ve had to slow down this flow which is a shame because this flow is really important for managing all our asynchronous API-calls and slowing down the schedule slows down a lot of processes for the users.

We would like to restore the rapid schedule. Using this rapid schedule is something that was recommended to us several times on this forum and I've seen posts of other users about fast schedules as well. It’s seems weird to me that nobody else has run into this problem before.
Is there something we can change to avoid this problem? I’ve considered making the flow loop instead of a rapidly restarting it but this doesn’t allow for multiple API calls to be executed simultaneously and some of the integrations are quite slow to respond.

The current fix I found was to change the stored procedure on the IAM database by making the process_flow_schedule_start query tables on the IAM databse instead of a view:

The original querying the view gui_appl_system_flow:

1--control_proc_id:      proc_process_flow_schedule_start
2--template_id:          proc_process_flow_schedule_start
3--prog_object_item_id:  proc_process_flow_schedule_start
4--template_description: 
5
6declare 
7    @model_id                           model_id,
8    @branch_id                          branch_id,
9    @schedule_id                        schedule_id,
10    @multiple_running_instances_allowed no_yes
11
12-- Find the currently active schedule for the pending flow
13select 
14    @model_id = f.model_id,
15    @branch_id = f.branch_id,
16    @schedule_id = f.schedule_id,
17    @multiple_running_instances_allowed = f.multiple_running_instances_allowed
18from gui_appl u 
19join gui_appl_system_flow f
20  on f.model_id = u.model_id
21 and f.branch_id = u.branch_id
22 and f.gui_appl_id = u.gui_appl_id
23where u.gui_appl_id = @gui_appl_id
24  and u.active = 1
25  and f.process_flow_id = @process_flow_id

Changed to:

1--control_proc_id:      proc_process_flow_schedule_start
2--template_id:          proc_process_flow_schedule_start
3--prog_object_item_id:  proc_process_flow_schedule_start
4--template_description: 
5
6declare 
7    @model_id                           model_id,
8    @branch_id                          branch_id,
9    @schedule_id                        schedule_id,
10    @multiple_running_instances_allowed no_yes
11
12-- Find the currently active schedule for the pending flow
13select
14@model_id = s.model_id,
15@branch_id = s.branch_id,
16@schedule_id = iif(i.model_id is not null, i.schedule_id, s.default_schedule_id),
17@multiple_running_instances_allowed = s.multiple_running_instances_allowed
18from gui_appl g 
19join sf_process_flow s
20  on s.model_id = g.model_id 
21 and s.branch_id = g.branch_id
22left join iam_process_flow i
23  on i.model_id = g.model_id
24 and i.branch_id = g.branch_id
25 and i.gui_appl_id = g.gui_appl_id
26 and i.process_flow_id = s.process_flow_id
27where g.gui_appl_id = @gui_appl_id
28and g.active = 1
29and s.process_flow_id = @process_flow_id
30and s.is_system_flow = 1
31and (     
32    s.iam_custom_schedule_allowed = 1 -- The user can configure custom schedules
33    or exists(                           -- There are schedules
34        select 1
35        from sf_process_flow_schedule o
36        where o.model_id = g.model_id
37          and o.branch_id = g.branch_id
38          and o.process_flow_id = s.process_flow_id
39    )
40)

This hugely improves the performance of this query and fixes our problem but it’s far from ideal since we wouldn’t like to maintain code changes on procedures provided by Thinkwise and we may unknowingly break things. It may be profitable for Thinkwise to change this, if so what is the best way to request this? Via an idea on this forum, TCP or some other way?