-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: hogql trends #17519
feat: hogql trends #17519
Conversation
with self.timings.measure("trends_query"): | ||
for series in self.query.series: | ||
queries.append( | ||
parse_select( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To support multiple series. Looks like we'll have to execute multiple queries (the current trends code does this too, but in parallel with multiple series). I had looked at using a UNION ALL
over multiple queries, but we could very easily hit max query limits given a bunch of series. Are there any alternatives that can be used here with Clickhouse / HogQL?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... Scope creep, but what about just multiple columns in the same query? E.g. select count(distinct person_id) as series1, count(id) as series_2, etc from event
The base from events
query is always the same for everyone --> all events + date range + global filters.
The individual event queries filter this further. E.g. "only $pageview with filters 1, 2, 3". This could be accomplished with something like:
select
countIf(distinct person_id, series_1_filters) as series1,
countIf(id, series_2_filters) as series_2
from event
where global_filters
This might break with DAU/MAU queries, but I'm not sure right now..
The global filters could then include the common filters (e.g. event='$pageview'
) if there are any to speed up the process, otherwise they'd read through all events. Doing a UNION ALL query, or doing multiple queries and aggregating the results, works... but is likely slower as you need to do multiple passes over the data.
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
b3c35df
to
13ccb57
Compare
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
📸 UI snapshots have been updated1 snapshot changes in total. 0 added, 1 modified, 0 deleted:
Triggered by this commit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a good start (but is gonna need tests)
from typing import Any, Dict, List | ||
|
||
|
||
class FormulaAST: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This deserves a small test suite of its own, so I propose adding formula support in separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Great work! Agreed re: tests though, but happy to add them in a followup.
de93691
to
c871b48
Compare
Problem
We want to move insight trends backend to use HogQL as opposed to the current janky filter query
Changes
Started off this work behind the hogql_insights feature flag. Got the trends insight rendering with some basic functionality:
Total Count
andHogQL Expression
math operatorsStill to do:
persons_urls
in response objactions
in response obj(anything else I've forgotten here?)
How did you test this code?
Only been testing in the browser so far. Some testing will be required on the new backend query runner