Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Bug]: ERROR: cannot create continuous aggregate with incompatible bucket width #5277

Closed
natebowang opened this issue Feb 3, 2023 · 3 comments · Fixed by #5304
Closed

[Bug]: ERROR: cannot create continuous aggregate with incompatible bucket width #5277

natebowang opened this issue Feb 3, 2023 · 3 comments · Fixed by #5304
Labels
bug

Comments

@natebowang
Copy link

natebowang commented Feb 3, 2023 •
edited

What type of bug is this?

Unexpected error

What subsystems and features are affected?

Continuous aggregate

What happened?

I want to create continuous aggregate c on top of another continuous aggregate b:

CREATE MATERIALIZED VIEW b WITH (timescaledb.continuous)
AS SELECT
    time_bucket('9344 ms', "time") as bucket9344,
    MAX(delay) as delay
FROM a
GROUP BY bucket9344
WITH NO DATA;
CREATE MATERIALIZED VIEW c WITH (timescaledb.continuous)
AS SELECT
    time_bucket('74752 ms', "bucket9344") as bucket74752,
    MAX(delay) as delay
FROM b
GROUP BY bucket74752
WITH NO DATA;

And I got this error:

ERROR: cannot create continuous aggregate with incompatible bucket width
DETAIL: Time bucket width of "c" [00:01:14.749] should be multiple of the time bucket width of "b" [00:00:09.344].

But 74752 ms is 8 times of 9344 ms. How can I create d?

Thanks

TimescaleDB version affected

2.9.2

PostgreSQL version used

14.6

What operating system did you use?

Docker image timescale/timescaledb:latest-pg14 on Archlinux host

What installation method did you use?

Docker

What platform did you run on?

On prem/Self-hosted

Relevant log output and stack trace

org.jkiss.dbeaver.model.sql.DBSQLException: SQL Error [0A000]: ERROR: cannot create continuous aggregate with incompatible bucket width
Detail: Time bucket width of "misc.c" [00:01:14.752] should be multiple of the time bucket width of "misc.b" [00:00:09.344].
at org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.executeStatement(JDBCStatementImpl.java:133)
at org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.executeStatement(SQLQueryJob.java:575)
at org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.lambda$1(SQLQueryJob.java:484)
at org.jkiss.dbeaver.model.exec.DBExecUtils.tryExecuteRecover(DBExecUtils.java:172)
at org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.executeSingleQuery(SQLQueryJob.java:491)
at org.jkiss.dbeaver.ui.editors.sql.execute.SQLQueryJob.extractData(SQLQueryJob.java:878)
at org.jkiss.dbeaver.ui.editors.sql.SQLEditor$QueryResultsContainer.readData(SQLEditor.java:3526)
at org.jkiss.dbeaver.ui.controls.resultset.ResultSetJobDataRead.lambda$0(ResultSetJobDataRead.java:118)
at org.jkiss.dbeaver.model.exec.DBExecUtils.tryExecuteRecover(DBExecUtils.java:172)
at org.jkiss.dbeaver.ui.controls.resultset.ResultSetJobDataRead.run(ResultSetJobDataRead.java:116)
at org.jkiss.dbeaver.ui.controls.resultset.ResultSetViewer$ResultSetDataPumpJob.run(ResultSetViewer.java:4868)
at org.jkiss.dbeaver.model.runtime.AbstractJob.run(AbstractJob.java:105)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.postgresql.util.PSQLException: ERROR: cannot create continuous aggregate with incompatible bucket width
Detail: Time bucket width of "misc.c" [00:01:14.752] should be multiple of the time bucket width of "misc.b" [00:00:09.344].
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2565)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2297)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:322)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:481)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:401)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:322)
at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:308)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:284)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:279)
at org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.execute(JDBCStatementImpl.java:329)
at org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.lambda$0(JDBCStatementImpl.java:131)
at org.jkiss.dbeaver.utils.SecurityManagerUtils.wrapDriverActions(SecurityManagerUtils.java:94)
at org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.executeStatement(JDBCStatementImpl.java:131)
... 12 more

How can we reproduce the bug?

CREATE TABLE IF NOT EXISTS a
(
    "time"  TIMESTAMPTZ(3) NOT NULL,
    "delay" numeric 
);

SELECT create_hypertable(
    'a',
    'time',
    if_not_exists => TRUE,
    chunk_time_interval => INTERVAL '1 m',
    create_default_indexes => FALSE
);

CREATE MATERIALIZED VIEW b WITH (timescaledb.continuous)
AS SELECT
    time_bucket('9344 ms', "time") as bucket9344,
    MAX(delay) as delay
FROM a
GROUP BY bucket9344
WITH NO DATA;

CREATE MATERIALIZED VIEW c WITH (timescaledb.continuous)
AS SELECT
    time_bucket('74752 ms', "bucket9344") as bucket74752,
    MAX(delay) as delay
FROM b
GROUP BY bucket74752
WITH NO DATA;
@natebowang natebowang added the bug label Feb 3, 2023
@natebowang natebowang changed the title [Bug]: Cannot create continuous aggregate with incompatible bucket width error [Bug]: ERROR: cannot create continuous aggregate with incompatible bucket width Feb 3, 2023
@natebowang natebowang changed the title [Bug]: ERROR: cannot create continuous aggregate with incompatible bucket width [Bug]: ERROR: cannot create continuous aggregate with incompatible bucket width Feb 3, 2023
@ilialloyd
Copy link

I think the time interval for "b" and "c" is different. Check this out

CREATE TABLE IF NOT EXISTS a
(
    "time"  TIMESTAMPTZ(3) NOT NULL,
    "delay" numeric 
);

SELECT create_hypertable(
    'a',
    'time',
    if_not_exists => TRUE,
    chunk_time_interval => INTERVAL '1 m',
    create_default_indexes => FALSE
);

CREATE MATERIALIZED VIEW b WITH (timescaledb.continuous)
AS SELECT
    time_bucket('74752 ms', "time") as bucket74752,
    MAX(delay) as delay
FROM a
GROUP BY bucket74752
WITH NO DATA;

CREATE MATERIALIZED VIEW c WITH (timescaledb.continuous)
AS SELECT
    time_bucket('74752 ms', "bucket74752") as bucket74752,
    MAX(delay) as delay
FROM b
GROUP BY bucket74752
WITH NO DATA;

The time interval for both 'b' and 'c' in this modified code is set to 74752 milliseconds, ensuring that both time intervals are the identical and preventing the occurrence of the error "ERROR: cannot construct continuous aggregate with incompatible bucket width."

@natebowang
Copy link
Author

natebowang commented Feb 3, 2023 •
edited

Thanks for the quick reply.

The time interval for "b" and "c" need to be different, because I want "c" down-sampling "b".

Here are the time bucket intervals I choose:

0 (raw hypertable)
=> 146 ms (the first aggregate) this aggregate successfully created
=> 1168 ms (8 times of 146) this aggregate successfully created
=> 9344 ms (8 times of 1168) this aggregate successfully created
=> 74752 ms (8 times of 9344) failed from here
=> 598016 ms (8 times of 74752)

@konskov
Copy link
Contributor

konskov commented Feb 3, 2023

Thanks for the bug report @natebowang. I can reproduce the issue

@konskov konskov self-assigned this Feb 3, 2023
konskov added a commit to konskov/timescaledb that referenced this issue Feb 10, 2023
@konskov
Support sub-second intervals in hierarchical caggs
97cc0c0 
Internally we use date_part("epoch", timestamp) and integer division
to determine whether the top cagg's interval is a multiple of
the parent's.
This would lead to loss of precision and incorrect results in the case
of intervals with sub-second components.
Fixed by multiplying by appropriate factors when possible to maintain
precision.

Fixes timescale#5277
@konskov konskov mentioned this issue Feb 10, 2023
Merged
konskov added a commit to konskov/timescaledb that referenced this issue Feb 10, 2023
@konskov
Support sub-second intervals in hierarchical caggs
d6459ba 
Internally we use date_part("epoch", timestamp) and integer division
to determine whether the top cagg's interval is a multiple of
the parent's.
This would lead to loss of precision and incorrect results in the case
of intervals with sub-second components.
Fixed by multiplying by appropriate factors when possible to maintain
precision.

Fixes timescale#5277
konskov added a commit to konskov/timescaledb that referenced this issue Feb 10, 2023
@konskov
Support sub-second intervals in hierarchical caggs
51c7dae 
Internally we use date_part("epoch", timestamp) and integer division
to determine whether the top cagg's interval is a multiple of
the parent's.
This would lead to loss of precision and incorrect results in the case
of intervals with sub-second components.
Fixed by multiplying by appropriate factors when possible to maintain
precision.

Fixes timescale#5277
konskov added a commit to konskov/timescaledb that referenced this issue Feb 10, 2023
@konskov
Support sub-second intervals in hierarchical caggs
20bd957 
Internally we use date_part("epoch", interval) and integer division
to determine whether the top cagg's interval is a multiple of
the parent's.
This would lead to loss of precision and incorrect results in the case
of intervals with sub-second components.
Fixed by multiplying by appropriate factors when possible to maintain
precision.

Fixes timescale#5277
@konskov konskov removed their assignment Feb 23, 2023
konskov added a commit to konskov/timescaledb that referenced this issue Mar 3, 2023
@konskov
Support sub-second intervals in hierarchical caggs
9472665 
Internally we use date_part("epoch", interval) to determine whether
the top cagg's interval is a multiple of its parent's.
Previously we were using integer division for this calculation and
integer bucket widths, leading to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using fmod for the division instead of integer division.

Fixes timescale#5277
konskov added a commit to konskov/timescaledb that referenced this issue Mar 3, 2023
@konskov
Support sub-second intervals in hierarchical caggs
66bfdc2 
Internally we use date_part("epoch", interval) to determine whether
the top cagg's interval is a multiple of its parent's.
Previously we were using integer division for this calculation and
integer bucket widths, leading to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using fmod for the division instead of integer division.

Fixes timescale#5277
konskov added a commit to konskov/timescaledb that referenced this issue Mar 6, 2023
@konskov
Support sub-second intervals in hierarchical caggs
0aec692 
Previously we used date_part("epoch", interval) and integer division
internally to determine whether the top cagg's interval is a
multiple of its parent's.
This led to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using the `ts_interval_value_to_internal` function to convert
intervals to appropriate integer representation for division.

Fixes timescale#5277
konskov added a commit to konskov/timescaledb that referenced this issue Mar 6, 2023
@konskov
Support sub-second intervals in hierarchical caggs
542a98d 
Previously we used date_part("epoch", interval) and integer division
internally to determine whether the top cagg's interval is a
multiple of its parent's.
This led to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using the `ts_interval_value_to_internal` function to convert
intervals to appropriate integer representation for division.

Fixes timescale#5277
konskov added a commit to konskov/timescaledb that referenced this issue Mar 6, 2023
@konskov
Support sub-second intervals in hierarchical caggs
04973b0 
Previously we used date_part("epoch", interval) and integer division
internally to determine whether the top cagg's interval is a
multiple of its parent's.
This led to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using the `ts_interval_value_to_internal` function to convert
intervals to appropriate integer representation for division.

Fixes timescale#5277
konskov added a commit to konskov/timescaledb that referenced this issue Mar 6, 2023
@konskov
Support sub-second intervals in hierarchical caggs
ac11a04 
Previously we used date_part("epoch", interval) and integer division
internally to determine whether the top cagg's interval is a
multiple of its parent's.
This led to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using the `ts_interval_value_to_internal` function to convert
intervals to appropriate integer representation for division.

Fixes timescale#5277
konskov added a commit to konskov/timescaledb that referenced this issue Mar 6, 2023
@konskov
Fix sub-second intervals in hierarchical caggs
06d685f 
Previously we used date_part("epoch", interval) and integer division
internally to determine whether the top cagg's interval is a
multiple of its parent's.
This led to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using the `ts_interval_value_to_internal` function to convert
intervals to appropriate integer representation for division.

Fixes timescale#5277
konskov added a commit to konskov/timescaledb that referenced this issue Mar 6, 2023
@konskov
Fix sub-second intervals in hierarchical caggs
dba6d38 
Previously we used date_part("epoch", interval) and integer division
internally to determine whether the top cagg's interval is a
multiple of its parent's.
This led to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using the `ts_interval_value_to_internal` function to convert
intervals to appropriate integer representation for division.

Fixes timescale#5277
konskov added a commit to konskov/timescaledb that referenced this issue Mar 7, 2023
@konskov
Fix sub-second intervals in hierarchical caggs
b97210d 
Previously we used date_part("epoch", interval) and integer division
internally to determine whether the top cagg's interval is a
multiple of its parent's.
This led to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using the `ts_interval_value_to_internal` function to convert
intervals to appropriate integer representation for division.

Fixes timescale#5277
konskov added a commit that referenced this issue Mar 7, 2023
@konskov
Fix sub-second intervals in hierarchical caggs
5a3cacd 
Previously we used date_part("epoch", interval) and integer division
internally to determine whether the top cagg's interval is a
multiple of its parent's.
This led to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using the `ts_interval_value_to_internal` function to convert
intervals to appropriate integer representation for division.

Fixes #5277
@timescale-automation timescale-automation mentioned this issue Mar 7, 2023
Merged
github-actions bot pushed a commit that referenced this issue Mar 7, 2023
@konskov @timescale-automation
Fix sub-second intervals in hierarchical caggs
22dfbcb 
Previously we used date_part("epoch", interval) and integer division
internally to determine whether the top cagg's interval is a
multiple of its parent's.
This led to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using the `ts_interval_value_to_internal` function to convert
intervals to appropriate integer representation for division.

Fixes #5277

(cherry picked from commit 5a3cacd)
timescale-automation pushed a commit that referenced this issue Mar 7, 2023
@konskov @timescale-automation
Fix sub-second intervals in hierarchical caggs
9282770 
Previously we used date_part("epoch", interval) and integer division
internally to determine whether the top cagg's interval is a
multiple of its parent's.
This led to precision loss and wrong results
in the case of intervals with sub-second components.

Fixed by using the `ts_interval_value_to_internal` function to convert
intervals to appropriate integer representation for division.

Fixes #5277

(cherry picked from commit 5a3cacd)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix sub-second intervals in hierarchical caggs konskov/timescaledb
3 participants
@natebowang @konskov @ilialloyd