-
Notifications
You must be signed in to change notification settings - Fork 47
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
Add timeline_agg #636
Add timeline_agg #636
Conversation
9d0ed0f
to
fb8da95
Compare
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.
Added a couple of nits about the layout of the StateAgg structure. Feel free to ignore these comments, they're probably both in the high effort, low reward category.
#[derive(Clone, Debug, Deserialize, Eq, FlatSerializable, PartialEq, Serialize)] | ||
#[repr(C)] | ||
pub struct TimeInState { | ||
start_time: i64, |
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.
minor nitpick, but it seems a bit wasteful to be always storing this when, for every value but the first, it will be the same as the end_time for the previous value.
|
||
#[derive(Clone, Debug, Deserialize, Eq, FlatSerializable, PartialEq, Serialize)] | ||
#[repr(C)] | ||
pub struct DurationInState { | ||
duration: i64, // TODO BRIAN is i64 or u64 the right type | ||
duration: i64, | ||
state_beg: u32, |
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.
We really should be able to store an array of strings in the same order as their duration information, though we don't currently have a flat serializable implementation for this. Even with that we'd have to store some index in each TimeInState
though, which would have to take up 64 bytes to be aligned, so it's not a big win.
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.
I would like to see if we can be a bit more efficient in our flattened format, but this looks good for an experimental release.
4997c37
to
327e22e
Compare
327e22e
to
33dc255
Compare
bors r+ |
Build succeeded:
|
640: Support rollup and integer states state/timeline aggs r=Smittyvb a=Smittyvb - Adds `rollup` for `state_agg` and `timeline_agg`. - Supports integer states for `state_agg` and `timeline_agg`. An aggregate can have integer states or string states, but not both. For a few functions this would mean having two functions with the same argument types but differing return types, so in that case I made a separate function for integer-valued aggregates (e.g. `state_int_timeline`). Ideally this should have been two separate PRs, but my changes to `rollup` and the rest of the `state_agg` code have become intertwined. (this should be merged after #636) Co-authored-by: Smitty <[email protected]> Co-authored-by: Smittyvb <[email protected]>
Adds a
timeline_agg
aggregate that can be used in the same ways asstate_agg
but also allows getting the entire state timeline withstate_timeline
.Note that this PR returns start times and end times instead of
tstzrange
s. pgx 0.6.0 will add support fortstzrange
s so when that release comes out I'll update the relevant functions to return ranges.This partially addresses #619 (adding
rollup
and supporting integer values will be separate PRs to make them easier to review).