./ql 'create table t(thing int, t time);'
./ql 'create index x on t(thing,t);'
./ql 'explain SELECT * FROM t WHERE thing = 3 AND t = now();'

┌Iterate all rows of table "t"
└Output field names ["thing" "t"]
┌Filter on thing == 3 && t == now()
│Possibly useful indices
│CREATE INDEX xt_thing ON t(thing);
└Output field names ["thing" "t"]

The idea behaviour would be for x to be a composite index, and for it to be used for all queries which have comparisons to thing and t.

This is a very common pattern for most customer-facing databases, where you need to filter on (at minimum) a user identifier and a timestamp, which should ideally have O(log n) performance (a customer with 1mil records should minimially impact the performance of another customer with only a few hundred records).

Based on my reading of ql/design implementing this is not possible without changing the low-level table representation.