Make CAgg time_bucket catalog table more generic #6624
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jnidzwetzki
force-pushed
the
refactor_cagg_catalog
branch
4 times, most recently
from
afb5194
to
a5c1266
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #6624 +/- ##
==========================================
+ Coverage 80.06% 81.51% +1.44%
==========================================
Files 190 190
Lines 37181 36378 -803
Branches 9450 9452 +2
==========================================
- Hits 29770 29652 -118
+ Misses 2997 2969 -28
+ Partials 4414 3757 -657 ☔ View full report in Codecov by Sentry. |
jnidzwetzki
force-pushed
the
refactor_cagg_catalog
branch
4 times, most recently
from
272b43d
to
6a4efdd
Compare
|
@mahipv, @nikkhils: please review this pull request.
|
jnidzwetzki
force-pushed
the
refactor_cagg_catalog
branch
from
6a4efdd
to
e38117d
Compare
akuzm
reviewed
Feb 9, 2024
akuzm
reviewed
Feb 9, 2024
akuzm
approved these changes
Feb 9, 2024
jnidzwetzki
force-pushed
the
refactor_cagg_catalog
branch
7 times, most recently
from
937ab01
to
d25f471
Compare
jnidzwetzki
added a commit
to jnidzwetzki/timescaledb
that referenced
this pull request
Feb 21, 2024
Historically, we have used an empty string for undefined values in the catalog table continuous_aggs_bucket_function. Since timescale#6624, the optional arguments can be NULL. This patch cleans up the empty strings and changes the logic to work with NULL values.
jnidzwetzki
added a commit
to jnidzwetzki/timescaledb
that referenced
this pull request
Feb 21, 2024
Historically, we have used an empty string for undefined values in the catalog table continuous_aggs_bucket_function. Since timescale#6624, the optional arguments can be NULL. This patch cleans up the empty strings and changes the logic to work with NULL values.
jnidzwetzki
added a commit
to jnidzwetzki/timescaledb
that referenced
this pull request
Feb 22, 2024
Historically, we have used an empty string for undefined values in the catalog table continuous_aggs_bucket_function. Since timescale#6624, the optional arguments can be NULL. This patch cleans up the empty strings and changes the logic to work with NULL values.
jnidzwetzki
added a commit
to jnidzwetzki/timescaledb
that referenced
this pull request
Feb 22, 2024
Historically, we have used an empty string for undefined values in the catalog table continuous_aggs_bucket_function. Since timescale#6624, the optional arguments can be NULL. This patch cleans up the empty strings and changes the logic to work with NULL values.
jnidzwetzki
added a commit
that referenced
this pull request
Feb 23, 2024
Historically, we have used an empty string for undefined values in the catalog table continuous_aggs_bucket_function. Since #6624, the optional arguments can be NULL. This patch cleans up the empty strings and changes the logic to work with NULL values.
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 15, 2024
In timescale#6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for FuncExpr and in certain cases we can have two different time_bucket function definition but what matters is the correct and valid time_bucket function that is part of the groupClause. Fixed it by inspecting only the Query->groupClause items to look for a valid time_bucket FuncExpr and return it Oid.
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 15, 2024
In timescale#6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for `FuncExpr` and in certain cases we can have two different `time_bucket` function definition but what matters is the correct and valid `time_bucket` function that is part of the `Query->groupClause`. Fixed it by inspecting only the `Query->groupClause` items looking for a valid time bucket `FuncExpr` and return it `Oid`.
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 15, 2024
In timescale#6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for `FuncExpr` and in certain cases we can have two different `time_bucket` function definition but what matters is the correct and valid `time_bucket` function that is part of the `Query->groupClause`. Fixed it by inspecting only the `Query->groupClause` items looking for a valid time bucket `FuncExpr` and return it `Oid`.
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 15, 2024
In timescale#6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for `FuncExpr` and in certain cases we can have two different `time_bucket` function definition but what matters is the correct and valid `time_bucket` function that is part of the `Query->groupClause`. Fixed it by inspecting only the `Query->groupClause` items looking for a valid time bucket `FuncExpr` and return it `Oid`.
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 15, 2024
In timescale#6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for `FuncExpr` and in certain cases we can have two different `time_bucket` function definition but what matters is the correct and valid `time_bucket` function that is part of the `Query->groupClause`. Fixed it by inspecting only the `Query->groupClause` items looking for a valid time bucket `FuncExpr` and return it `Oid`.
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 16, 2024
In timescale#6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for `FuncExpr` and in certain cases we can have two different `time_bucket` function definition but what matters is the correct and valid `time_bucket` function that is part of the `Query->groupClause`. Fixed it by inspecting only the `Query->groupClause` items looking for a valid time bucket `FuncExpr` and return it `Oid`.
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 17, 2024
In timescale#6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for `FuncExpr` and in certain cases we can have two different `time_bucket` function definition but what matters is the correct and valid `time_bucket` function that is part of the `Query->groupClause`. Fixed it by inspecting only the `Query->groupClause` items looking for a valid time bucket `FuncExpr` and return it `Oid`.
fabriziomello
added a commit
that referenced
this pull request
May 17, 2024
In #6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for `FuncExpr` and in certain cases we can have two different `time_bucket` function definition but what matters is the correct and valid `time_bucket` function that is part of the `Query->groupClause`. Fixed it by inspecting only the `Query->groupClause` items looking for a valid time bucket `FuncExpr` and return it `Oid`.
github-actions bot
pushed a commit
that referenced
this pull request
May 17, 2024
In #6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for `FuncExpr` and in certain cases we can have two different `time_bucket` function definition but what matters is the correct and valid `time_bucket` function that is part of the `Query->groupClause`. Fixed it by inspecting only the `Query->groupClause` items looking for a valid time bucket `FuncExpr` and return it `Oid`. (cherry picked from commit 54830d1)
fabriziomello
added a commit
that referenced
this pull request
May 17, 2024
In #6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for `FuncExpr` and in certain cases we can have two different `time_bucket` function definition but what matters is the correct and valid `time_bucket` function that is part of the `Query->groupClause`. Fixed it by inspecting only the `Query->groupClause` items looking for a valid time bucket `FuncExpr` and return it `Oid`. (cherry picked from commit 54830d1)
timescale-automation
pushed a commit
that referenced
this pull request
May 17, 2024
In #6624 we refactored time_bucket catalog table to be more generic and introduced the `cagg_get_bucket_function` to inspect the query tree of a given Continuous Aggregate and return the time_bucket function oid. The problem with the implementation is we traverse the whole query tree looking for `FuncExpr` and in certain cases we can have two different `time_bucket` function definition but what matters is the correct and valid `time_bucket` function that is part of the `Query->groupClause`. Fixed it by inspecting only the `Query->groupClause` items looking for a valid time bucket `FuncExpr` and return it `Oid`. (cherry picked from commit 54830d1)
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 21, 2024
In timescale#6624 we refactored the time bucket catalog table to make it more generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information. The problem is we used the `regprocedure` type to store the OID of the given time bucket function but unfortunately it is not supported by `pg_upgrade`. Fixed it by changing the column to TEXT and resolve to/from OID using builtin `regprocedurein` and `format_procedure_qualified` functions. Fixes timescale#6935
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 21, 2024
In timescale#6624 we refactored the time bucket catalog table to make it more generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information. The problem is we used the `regprocedure` type to store the OID of the given time bucket function but unfortunately it is not supported by `pg_upgrade`. Fixed it by changing the column to TEXT and resolve to/from OID using builtin `regprocedurein` and `format_procedure_qualified` functions. Fixes timescale#6935
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 21, 2024
In timescale#6624 we refactored the time bucket catalog table to make it more generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information. The problem is we used the `regprocedure` type to store the OID of the given time bucket function but unfortunately it is not supported by `pg_upgrade`. Fixed it by changing the column to TEXT and resolve to/from OID using builtin `regprocedurein` and `format_procedure_qualified` functions. Fixes timescale#6935
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 21, 2024
In timescale#6624 we refactored the time bucket catalog table to make it more generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information. The problem is we used the `regprocedure` type to store the OID of the given time bucket function but unfortunately it is not supported by `pg_upgrade`. Fixed it by changing the column to TEXT and resolve to/from OID using builtin `regprocedurein` and `format_procedure_qualified` functions. Fixes timescale#6935
fabriziomello
added a commit
to fabriziomello/timescaledb
that referenced
this pull request
May 22, 2024
In timescale#6624 we refactored the time bucket catalog table to make it more generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information. The problem is we used the `regprocedure` type to store the OID of the given time bucket function but unfortunately it is not supported by `pg_upgrade`. Fixed it by changing the column to TEXT and resolve to/from OID using builtin `regprocedurein` and `format_procedure_qualified` functions. Fixes timescale#6935
fabriziomello
added a commit
that referenced
this pull request
May 22, 2024
In #6624 we refactored the time bucket catalog table to make it more generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information. The problem is we used the `regprocedure` type to store the OID of the given time bucket function but unfortunately it is not supported by `pg_upgrade`. Fixed it by changing the column to TEXT and resolve to/from OID using builtin `regprocedurein` and `format_procedure_qualified` functions. Fixes #6935
github-actions bot
pushed a commit
that referenced
this pull request
May 22, 2024
In #6624 we refactored the time bucket catalog table to make it more generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information. The problem is we used the `regprocedure` type to store the OID of the given time bucket function but unfortunately it is not supported by `pg_upgrade`. Fixed it by changing the column to TEXT and resolve to/from OID using builtin `regprocedurein` and `format_procedure_qualified` functions. Fixes #6935 (cherry picked from commit 8b994c7)
fabriziomello
added a commit
that referenced
this pull request
May 22, 2024
In #6624 we refactored the time bucket catalog table to make it more generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information. The problem is we used the `regprocedure` type to store the OID of the given time bucket function but unfortunately it is not supported by `pg_upgrade`. Fixed it by changing the column to TEXT and resolve to/from OID using builtin `regprocedurein` and `format_procedure_qualified` functions. Fixes #6935 (cherry picked from commit 8b994c7)
fabriziomello
added a commit
that referenced
this pull request
May 22, 2024
In #6624 we refactored the time bucket catalog table to make it more generic and save information for all Continuous Aggregates. Previously it stored only variable bucket size information. The problem is we used the `regprocedure` type to store the OID of the given time bucket function but unfortunately it is not supported by `pg_upgrade`. Fixed it by changing the column to TEXT and resolve to/from OID using builtin `regprocedurein` and `format_procedure_qualified` functions. Fixes #6935 (cherry picked from commit 8b994c7)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The catalog table continuous_aggs_bucket_function is currently only used for variable bucket sizes. Information about the fixed-size buckets is stored in the table continuous_agg only. This causes some problems (e.g., we have redundant fields for the bucket_size, fixes size buckets with offsets are not supported, ...).
This commit is the first in a row of commits that refactor the catalog for the CAgg time_bucket function. The goals are:
This first commit refactors the continuous_aggs_bucket_function table and prepares it for more generic use. Not all attributes are used yet, but these will change in follow-up PRs.
Should be merged after: #6661
Disable-check: force-changelog-file