Backlog occurs when the throughput exceeds the current table configuration resulting in high values for TotalQueuedTuples.

Table results may be delayed for any query regardless of how simple the query is and how small the result set if the table is backlogged. The TotalQueuedTuples column from the LiveViewStatistics table will show any backlog:

$ lv-client.cmd "select TableName, TotalQueuedTuples from LiveViewStatistics"
+--------------------+-------------------+
| TableName          | TotalQueuedTuples |
+--------------------+-------------------+
| LiveViewStatistics |                 0 |
| LVAlerts           |                 0 |
| data               |             18692 |
+--------------------+-------------------+

A backlog which will cause delays noticeable in the client is 15000 tuples and greater. This effect is the same whether the table has a small number of rows or millions of rows, but it is more likely with a large table since more rows could be returned in the result set (increasing the amount of queued data).

The table will become backlogged when the quantity of row updates into the table and the quantity of query results out from the table exceeds the table's processing capacity.

With a simple table consisting of ("ts" timestamp primary-key, "val" double), at 100 tps (tuples per second) row inserts/updates per second, no backlog occurred with query:
  select * from data order by ts desc limit 2000
but if the table was seeing 400 tps updates, then the same query would start to cause backlog and while that backlog existed, if the query was stopped/paused and restarted, it would take many seconds to start to report in the client as its result-set moved through the queue. Note: This example query is expensive because it requests the server to sort 2000 rows for every update. A good limit value for an "order by" statement is 30 rows.

In practice you may run query "select TableName, TotalQueuedTuples from LiveViewStatistics" before you submit your intended query to see if the table is backlogged.

• If the table is backlogged, then your query results will be delayed.
• If the table is NOT backlogged, then your query to report within a small number of seconds.

When your query is running, see if the backlog is getting worse. If so, then the next query to that table will not report results until such time as the backlog is resolved. It is possible for query results to start to be seen before the backlog is fully resolved simply because that query's results have started to make it through the queue.

A secondary indication that a table is backlogged is when you see in the server console log messages like this:

INFO LVMonitor - Large queue backup: Name "{Table}.DataUnionRef1.SnapCacheRef1:ParallelSequence"
INFO LVMonitor - Thread Busy: Name "{Table}.DataUnionRef1.SnapCacheRef1: Queue handler"

If these are appearing frequently then the affected tables and associated queries require additional tuning to make them more efficient by reducing the number or row-updates per second, or reducing the complexity of the full set of queries the table is supporting at the same time.

Backlog occurs when the throughput exceeds the current table configuration resulting in high values for TotalQueuedTuples.