deceptive `jit=` flag in `QueryProgress` log output

To reproduce

When running queries, query progress is reported using a pair of exe and fin statements. Unfortunately, the jit label is not implemented correctly.

This means you can start a query with no JIT, but finish it with JIT.

2025-04-22T15:01:01.433405Z I i.q.g.e.QueryProgress exe [id=837, sql=`tab where col1 in ($1) and status = $2 and ts >= 0 latest on ts partition by status `, principal=admin, cache=true, jit=false]
2025-04-22T15:01:01.433538Z I i.q.g.e.QueryProgress fin [id=837, sql=`tab where col1 in ($1) and status = $2 and ts >= 0 latest on ts partition by status `, principal=admin, cache=true, jit=true, time=135800]

This is because logStart accepts a boolean jit argument. This is populated by checking if the query uses a compiled filter.

However, logEnd and logError do not have this. Instead, they report whether or not jit is enabled globally:

boolean isJit = executionContext.getJitMode() != SqlJitMode.JIT_MODE_DISABLED;

This leads to confusing logs.

QuestDB version:

Master (8.3.0+)

OS, in case of Docker specify Docker and the Host OS:

N/A

File System, in case of Docker specify Host File System:

N/A

Full Name:

Nick Woolmer

Affiliation:

QuestDB

Have you followed Linux, MacOs kernel configuration steps to increase Maximum open files and Maximum virtual memory areas limit?

• Yes, I have

Additional context

No response

Locate the query-progress logging code containing logStart, logEnd, and logError, then trace how the compiled-filter JIT value is determined for each statement. Compare the exe and fin output for the reproduction query, and consider the issue done when all corresponding log entries report the query's actual JIT state consistently.