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 Hierarchical Continuous Aggregates validations #5013
Add Hierarchical Continuous Aggregates validations #5013
Conversation
Codecov Report
@@ Coverage Diff @@
## main #5013 +/- ##
==========================================
+ Coverage 89.58% 89.64% +0.05%
==========================================
Files 226 227 +1
Lines 51347 51599 +252
==========================================
+ Hits 46001 46256 +255
+ Misses 5346 5343 -3
Continue to review full report at Codecov.
|
9ef42fb
to
55d4077
Compare
55d4077
to
29bf538
Compare
Thanks for adding nested caggs! I have a quick question about this sentence:
What exactly does "multiple" mean? Can I only build 24h on top of 1h (i.e. always the same multiple)? Or can I also build 1 day on top of 1 hour or 1 month on top of 1 day (i.e. variable multiple (most days have 24 hours, some 23/25; months can have 28-31 days) - of course respecting boundaries in the specified time zone)? We would need both to work, if that's not too much effort :) |
4b499bf
to
62077b4
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.
In general, this looks quite good, but I would consider the following:
- Using errors for cases that we think are not sensible might block users from interesting use-cases. I think a warning would be sufficient for these cases. Errors should be reserved for situations that will just not work.
- I think you should avoid enabling verbose message for entire tests and just increase and decrease the message level based on what is necessary. Maintaining tests with a lot of extraneous false mismatches takes extra time and risk missing actual failures.
- I think you're missing one test case.
tsl/src/continuous_aggs/create.c
Outdated
if ((bucket_info_source.bucket_width == BUCKET_WIDTH_VARIABLE && | ||
bucket_info.bucket_width != BUCKET_WIDTH_VARIABLE)) | ||
{ | ||
ereport(ERROR, | ||
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED), | ||
errmsg("cannot create continuous aggregate with fixed-width bucket on top of " | ||
"one using variable-width bucket"), | ||
errdetail("Continuous aggregate with a fixed time bucket width (e.g. 61 days) " | ||
"cannot be created on top of one using variable time bucket width " | ||
"(e.g. 1 month).\n" | ||
"The variance can lead to the fixed width one not being a multiple " | ||
"of the variable width one."))); |
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.
Not sure if this includes the case where you build one week (that is, 7 days) on top of days with DST. This should be conceptually OK, but not sure if you count such as a week as a variable width bucket or a fixed width bucket.
The same applies building a year (12 months) from months (which varies), but creating a continuous aggregate seems to mark a month bucket as variable, and also a year (using 12 months for a year), so this does not seem to be an issue.
This also have the risk of blocking the user if we have a bug in our code, so unless proceeding with execution when you have fixed-size buckets on top of variable width buckets would break the system, I think it would be sufficient with a warning message.
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 discussed a lot already about it (see the issue https://github.com/timescale/product/issues/337) and we decided to be more restrictive in this first version and perhaps relax it (or make it configurable) in the future.
0701169
to
f954c2b
Compare
All use cases you mentioned are supported, but the following:
|
3d54fe6
to
e06f27b
Compare
Commit 3749953 introduce Hierarchical Continuous Aggregates (aka Continuous Aggregate on top of another Continuous Aggregate) but it lacks of some basic validations. Validations added during the creation of a Hierarchical Continuous Aggregate: * Forbid create a continuous aggregate with fixed-width bucket on top of a continuous aggregate with variable-width bucket. * Forbid incompatible bucket widths: - should not be equal; - bucket width of the new continuous aggregate should be greater than the source continuous aggregate; - bucket width of the new continuous aggregate should be multiple of the source continuous aggregate.
e06f27b
to
3c6d16a
Compare
Thank you, @fabriziomello ! The not-working cases you listed make sense. |
Commit 3749953 introduce Hierarchical Continuous Aggregates (aka
Continuous Aggregate on top of another Continuous Aggregate) but it
lacks of some basic validations.
Validations added during the creation of a Hierarchical Continuous
Aggregate:
Forbid create a continuous aggregate with fixed-width bucket on top of
a continuous aggregate with variable-width bucket.
Forbid incompatible bucket widths:
the source continuous aggregate;
the source continuous aggregate.