QR: Target Apply latency metric for postgres destination with triggers

[Jon_Donker]

Hi Team,

We have a QR task set up like this:

As part of stress and volume testing; our question is whether Qlik’s Apply Latency metric considers the latency involved not just with the replication of the given record to the target table, but any subsequent functions that may be triggered on the target from that record being applied (eg applying to downstream_table).

Our scenario is that Qlik is replicating to a Postgres target, with DB triggers attached to the replicated target tables to perform subsequent operations in other tables (tables that exist only in the target).

According to postgres documentation, triggers are considered to be included within the transaction of the underlying operation that triggered it. If the trigger fails, the underlying operation that triggered it is not committed.  In this case, we’d expect that if the trigger function failed, the write that caused it would also be rolled back (resulting in Qlik reflecting an apply error).

We would also then expect that the clock doesn’t stop on latency until the entire transaction has been committed in target, therefore including the trigger function in the overall latency figure.

Are our assumptions correct here?

Thanks in advance.

[boaz_newman · Accepted solution]

Hello

Yes, your assumptions are correct for any relational db - triggers are part of a transaction, so the commit time on the target includes the trigger execution time, and therefor it affects the latency calculations.

boaz