Skip to main content
16-Pearl
August 13, 2026
Question

Best Practice for Handling Large SQL Queries (40+ Seconds) That Run Only a Few Times Per Month?

  • August 13, 2026
  • 5 replies
  • 121 views

Hi everyone,

I have a scenario where a very large SQL query processes data from multiple large tables and applies different joins, filters, and calculations before producing the final output. The execution time can sometimes reach 40+ seconds.

One important detail is that this process is not a frequent operation. It only occurs about 3 times per month, so optimizing for high-volume traffic is not a requirement.

Because of this, I'm questioning whether implementing a full asynchronous processing architecture is worth the added complexity. At the same time, simply increasing server timeouts doesn't feel like the best practice.

For a low-frequency but resource-intensive operation like this, what would you recommend?

 

 

  • What approach have you used for similar low-frequency, long-running database operations?

I'd appreciate any recommendations or real-world experiences.

Thanks in advance! 

5 replies

Rocko
19-Tanzanite
August 13, 2026

Run it directly in the DB. You can have scheduled jobs in the DB that create (or update) materialized views (or a similar concept). TWX then just gets the precomputed data. This is DB reporting, nothing you would put onto an IOT platform.

16-Pearl
August 14, 2026

Not sure how you trigger the SQL currently, but if with SQLThing: You can set query timeout per service:

Which is great :) PTC support showed me that option and I was amazed as I did not spot it myself.

 

16-Pearl
August 27, 2026

In my current implementation, I have 8 different update services, but instead of running them all at once, I execute them sequentially through a single scheduled service that runs every 30 seconds.

I use a property (for example, syncCounter as shown in the screenshot) to store the current iteration/state. Each time the timer service executes, it checks the counter value and runs only the corresponding update service:

  • Iteration 1 → Run Service 1, update counter to 2, then exit.
  • Iteration 2 → Run Service 2, update counter to 3, then exit.
  • Iteration 3 → Run Service 3, and so on.

After the last service runs, the counter is reset and the cycle starts again.

This is currently a temporary solution because each individual service takes only around 10 seconds to complete. By spreading the workload across multiple timer executions, I avoid running all 8 updates simultaneously and reduce the impact on the platform.

In the future, I may move more of the processing into SQL Server and let the database handle the updates directly, which could further improve performance. However, for the current workload and update frequency, this approach has been working reliably.

 

This strategy may not be ideal for very long-running operations, but for low-frequency updates with manageable execution times, it can be a practical and simple solution.

 

 

switch (me.syncCounter) {

case 1:
me.serviceOne();
logger.info("serviceOne gestartet");
break;

case 2:
me.serviceTwo();
logger.info("serviceTwo gestartet");
break;

case 3:
me.serviceThree();
logger.info("serviceThree gestartet");
break;

case 4:
me.serviceFour();
logger.info("serviceFour gestartet");
break;

case 5:
me.serviceFive();
logger.info("serviceFive gestartet");
break;

case 6:
me.serviceSix();
logger.info("serviceSix gestartet");
break;

case 7:
me.serviceSeven();
logger.info("serviceSeven gestartet");
break;
}

 

16-Pearl
September 1, 2026

Sounds pragmatic and works :)

I also do sometimes call all calls sequentially in same timer run. But depends on duration and db load yes. But we also have quite high script timeout - I think 10minutes or so. So we are not too limited from platform script timeout.

To prevent timer callbacks to run in parallel we also often introduce a “isRunning” property which the timer sets to “true” and in finally to “false”. And on callback start we check if its false, if so we can start, otherwise discard. It’s also not bulletproof mechanism (e.g. if event queue is high there might be multiple timer events executed at the same time) but works most times ;)

 

I may have misinterpreted your question initially. I thought your issue was that for some sql services you would want to increase general db query timeouts. But that does not seem to be your question. And your mechanism is good to do the job (besides the potential issue with each 30seconds, where the previous callback might still be active) ;)

Support
August 19, 2026

Hello ​@MA8731174,

 

I hope you are doing well!

 

Just following up on your post. I see that a few community members have shared their suggestions. If one of the responses resolved your issue, please mark it as the Best Answer so it can help others facing the same situation.

 

If you're still experiencing the issue or need any additional assistance, please let the community know.

 

Regards,

Abhi