I also don't really like the way queries are written in GB, they don't look very optimal, at least for my cases with ClickHouse. Often a query is made WITH first the full table, then from it the data is filtered by conditions for the experiment. Here I showed how the query is sped up by half simply by moving the filters around, using an example of one of the queries I copied from GB: https://www.diffchecker.com/QVthzUpn/ Anyway, GB is great!

Hey Valdislav! They're written this way because we let people write fairly arbitrary SQL as their Fact Table and Experiment Assignment query definitions, so we have to build the queries like that. Furthermore, most SQL engines do a good job of passing the filters inwards and upwards; BQ for example will take those date filters on the second CTE and apply them to the base table to scan fewer rows. I'm a bit surprised to see ClickHouse not doing the same, or at least not doing the same in all cases. However, you can use query template variables like

{{ startDate }}

to improve the performance of your queries by injecting the dates directly into the SQL you write: https://docs.growthbook.io/app/query-optimization#sql-template-variables

Thanks again. I've seen template variables, but trying to use fact tables everywhere, and didn't understand how to use it there.