And honestly it still wasn’t great because it migrated the clause down further than I wanted

pass that index as datoms, perhaps? not sure

not sure I like this idea much ^

Hey @U09R86PA4, just trying to understand the scenario here. The following information would be very helpful to give me enough context to understand what's going on here: • The query you were running • https://docs.datomic.com/pro/api/query-stats.html + https://docs.datomic.com/pro/api/io-stats.html • Cardinalities of values for respective E/A (rough estimate is fine) • Schema for attributes used in the query To answer your question, boundness of your logic variables (along with other criteria) is what determines which index is consulted for answers, and you there currently isn't a way to influence which index the query engine consults. If you've encountered a scenario where the decision made by the query engine is highly insufficient, I think that's a very interesting scenario that I really want to better understand.

It’s a lot for me to put together. I can paste you the relevant stuff I still had in a buffer, it’s really quite straightforward

{:find [?wfs-idx ?story-pos ?entity-id],
 :in [$ % [?type ...] [[?wfs-idx ?wfs]]],
 :where [[?wfs :workflow-state/type ?type]
         [(my-ns/wfs->story+pos $ ?wfs) [[?entity-id ?story-pos]]]]}

is the query

?wfs and ?type are both bound

This is the choice it made:

:clauses [{:clause [(ground $__in__3) [?type ...]],
           :rows-in 0,
           :rows-out 3,
           :binds-in (),
           :binds-out [?type],
           :expansion 3}
          {:clause [?wfs :workflow-state/type ?type],
           :rows-in 3,
           :rows-out 4312467,
           :binds-in [?type],
           :binds-out [?wfs],
           :expansion 4312464}
          {:clause [(ground $__in__4) [[?wfs-idx ?wfs]]],
           :rows-in 4312467,
           :rows-out 9,
           :binds-in [?wfs],
           :binds-out [?wfs ?wfs-idx]}

Note the expansion to 4million rows

this is a cardinality-one ref attribute

the trouble is ?type is an enum entity shared by the entire db

?wfs is a particular record

if ?wfs is known, then AEVT is 1 row

would changing the argument order of :in influence this?

so it does the third clause first instead of what it just did here?

Oh very interesting! :bind-in [?type] implies that the result set contained 3 rows consisting of only ?type #{[?type] [?type] [?type]} Do you observe different behavior if you pass ?wfs in directly like this: :in [$ % [?type ...] ?wfs-idx ?wfs] ?

I’m not sure what you mean by “directly”, it’s already an in-var; your proposal just removes the destructuring?

I have many (but not 4 million!) ?wfs

Correct - removing the destructuring. "directly" wasn't the best word to describe that

I think 8 in the query I was testing

You might also be able to force the query engine to bind ?wfs early by placing a ground clause in the beginning (just to better understand if the delayed binding is what's causing the problematic join behavior). Something like: [(identity ?wfs) ?wfs2] then use ?wfs2 in subsequent clauses Obviously this wouldn't be a solution, but more to better understand what we're seeing here

I’m going to have to get back to you on that, but thanks for the new things to try

Just fyi for when you get some time to test: I did a small test just now and it seems to have the effect we were (or I was) hoping to achieve. Curious to hear your findings.