Cleanup invalidations tests

This change adds views for invalidation tables to simplify queries in
the test.
This commit is contained in:
Erik Nordström 2020-09-24 12:50:08 +02:00 committed by Erik Nordström
parent 608d52dffc
commit 2ecfefc2fd
2 changed files with 125 additions and 296 deletions

View File

@ -130,6 +130,18 @@ ORDER BY 1 DESC, 2;
--------+--------+----------
(0 rows)
CREATE VIEW hyper_invals AS
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
CREATE VIEW cagg_invals AS
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
-- Must refresh to move the invalidation threshold, or no
-- invalidations will be generated. Initially, there is no threshold
-- set:
@ -141,13 +153,12 @@ ORDER BY 1,2;
-- There should be only "infinite" invalidations in the cagg
-- invalidation log:
SELECT * FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
materialization_id | modification_time | lowest_modified_value | greatest_modified_value
--------------------+-------------------+-----------------------+-------------------------
3 | 100 | -9223372036854775808 | 9223372036854775807
4 | 100 | -9223372036854775808 | 9223372036854775807
5 | 100 | -9223372036854775808 | 9223372036854775807
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | 9223372036854775807
4 | -9223372036854775808 | 9223372036854775807
5 | -9223372036854775808 | 9223372036854775807
(3 rows)
-- Now refresh up to 50, and the threshold should be updated accordingly:
@ -160,14 +171,13 @@ ORDER BY 1,2;
(1 row)
-- Invalidations should be cleared for the refresh window:
SELECT * FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
materialization_id | modification_time | lowest_modified_value | greatest_modified_value
--------------------+-------------------+-----------------------+-------------------------
3 | 100 | -9223372036854775808 | -1
3 | 100 | 50 | 9223372036854775807
4 | 100 | -9223372036854775808 | 9223372036854775807
5 | 100 | -9223372036854775808 | 9223372036854775807
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
3 | 50 | 9223372036854775807
4 | -9223372036854775808 | 9223372036854775807
5 | -9223372036854775808 | 9223372036854775807
(4 rows)
-- Refreshing below the threshold does not move it:
@ -182,14 +192,13 @@ ORDER BY 1,2;
-- Nothing changes with invalidations either since the region was
-- already refreshed and no new invalidations have been generated:
SELECT * FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
materialization_id | modification_time | lowest_modified_value | greatest_modified_value
--------------------+-------------------+-----------------------+-------------------------
3 | 100 | -9223372036854775808 | -1
3 | 100 | 50 | 9223372036854775807
4 | 100 | -9223372036854775808 | 9223372036854775807
5 | 100 | -9223372036854775808 | 9223372036854775807
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
3 | 50 | 9223372036854775807
4 | -9223372036854775808 | 9223372036854775807
5 | -9223372036854775808 | 9223372036854775807
(4 rows)
-- Refreshing measure_10 moves the threshold only for the other hypertable:
@ -202,15 +211,14 @@ ORDER BY 1,2;
2 | 30
(2 rows)
SELECT * FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
materialization_id | modification_time | lowest_modified_value | greatest_modified_value
--------------------+-------------------+-----------------------+-------------------------
3 | 100 | -9223372036854775808 | -1
3 | 100 | 50 | 9223372036854775807
4 | 100 | -9223372036854775808 | 9223372036854775807
5 | 100 | -9223372036854775808 | -1
5 | 100 | 30 | 9223372036854775807
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
3 | 50 | 9223372036854775807
4 | -9223372036854775808 | 9223372036854775807
5 | -9223372036854775808 | -1
5 | 30 | 9223372036854775807
(5 rows)
-- Refresh on the second continuous aggregate, cond_20, on the first
@ -224,33 +232,25 @@ ORDER BY 1,2;
2 | 30
(2 rows)
SELECT * FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
materialization_id | modification_time | lowest_modified_value | greatest_modified_value
--------------------+-------------------+-----------------------+-------------------------
3 | 100 | -9223372036854775808 | -1
3 | 100 | 50 | 9223372036854775807
4 | 100 | -9223372036854775808 | 59
4 | 100 | 100 | 9223372036854775807
5 | 100 | -9223372036854775808 | -1
5 | 100 | 30 | 9223372036854775807
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
3 | 50 | 9223372036854775807
4 | -9223372036854775808 | 59
4 | 100 | 9223372036854775807
5 | -9223372036854775808 | -1
5 | 30 | 9223372036854775807
(6 rows)
-- There should be no hypertable invalidations initially:
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
hyper_id | start | end
----------+-------+-----
(0 rows)
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
@ -270,11 +270,7 @@ INSERT INTO conditions VALUES (10, 4, 23.7);
INSERT INTO conditions VALUES (10, 5, 23.8), (19, 3, 23.6);
INSERT INTO conditions VALUES (60, 3, 23.7), (70, 4, 23.7);
-- Should see some invaliations in the hypertable invalidation log:
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
hyper_id | start | end
----------+-------+-----
1 | 10 | 10
@ -286,11 +282,7 @@ SELECT hypertable_id AS hyper_id,
INSERT INTO measurements VALUES (20, 4, 23.7);
INSERT INTO measurements VALUES (30, 5, 23.8), (80, 3, 23.6);
-- Should now see invalidations for both hypertables
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
hyper_id | start | end
----------+-------+-----
1 | 10 | 10
@ -315,21 +307,13 @@ ORDER BY 1,2;
-- Invalidations should be moved from the hypertable invalidation log
-- to the continuous aggregate log, but only for the hypertable that
-- the refreshed aggregate belongs to:
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
hyper_id | start | end
----------+-------+-----
2 | 20 | 20
(1 row)
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
@ -360,11 +344,7 @@ INSERT INTO conditions VALUES (3, 2, 23.5), (80, 1, 23.4);
INSERT INTO conditions VALUES (60, 3, 23.6), (90, 3, 23.6);
INSERT INTO conditions VALUES (20, 5, 23.8), (100, 3, 23.6);
-- New invalidations in the hypertable invalidation log:
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
hyper_id | start | end
----------+-------+-----
1 | 1 | 25
@ -379,11 +359,7 @@ SELECT hypertable_id AS hyper_id,
(9 rows)
-- But nothing has yet changed in the cagg invalidation log:
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
@ -401,22 +377,14 @@ SELECT materialization_id AS cagg_id,
CALL refresh_continuous_aggregate('cond_10', 20, 60);
-- Invalidations should be moved from the hypertable invalidation log
-- to the continuous aggregate log.
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
hyper_id | start | end
----------+-------+-----
2 | 20 | 20
(1 row)
-- Only the cond_10 cagg should have its entries cut:
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
@ -434,11 +402,7 @@ SELECT materialization_id AS cagg_id,
-- Refresh also cond_20:
CALL refresh_continuous_aggregate('cond_20', 20, 60);
-- The cond_20 cagg should also have its entries cut:
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
@ -453,11 +417,7 @@ SELECT materialization_id AS cagg_id,
-- Refresh cond_10 to completely remove an invalidation:
CALL refresh_continuous_aggregate('cond_10', 1, 20);
-- The 1-19 invalidation should be deleted:
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
@ -475,11 +435,7 @@ CALL refresh_continuous_aggregate('cond_10', 0, 100);
INSERT INTO conditions VALUES (20, 1, 23.4), (25, 1, 23.4);
INSERT INTO conditions VALUES (30, 1, 23.4), (46, 1, 23.4);
CALL refresh_continuous_aggregate('cond_10', 1, 40);
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
@ -498,11 +454,7 @@ SELECT materialization_id AS cagg_id,
INSERT INTO conditions VALUES (15, 1, 23.4), (42, 1, 23.4);
CALL refresh_continuous_aggregate('cond_10', 90, 100);
NOTICE: continuous aggregate "cond_10" is already up-to-date
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+---------------------
3 | -9223372036854775808 | -1
@ -519,11 +471,7 @@ SELECT materialization_id AS cagg_id,
-- Test max refresh window
CALL refresh_continuous_aggregate('cond_10', NULL, NULL);
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
cagg_id | start | end
---------+----------------------+----------------------
3 | -9223372036854775808 | -9223372036854775801
@ -537,11 +485,7 @@ SELECT materialization_id AS cagg_id,
5 | 30 | 9223372036854775807
(9 rows)
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
hyper_id | start | end
----------+-------+-----
2 | 20 | 20
@ -556,11 +500,7 @@ SELECT * FROM conditions;
(0 rows)
-- Should see an infinite invalidation entry for conditions
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
hyper_id | start | end
----------+----------------------+---------------------
1 | -9223372036854775808 | 9223372036854775807
@ -718,11 +658,7 @@ FROM _timescaledb_catalog.continuous_agg
WHERE user_view_name = 'cond_1' \gset
-- Test invalidations with bucket size 1
INSERT INTO conditions VALUES (0, 1, 1.0);
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
hyper_id | start | end
----------+-------+-----
1 | 0 | 0
@ -746,12 +682,8 @@ ORDER BY 1,2;
-- Refresh only the invalidated bucket
CALL refresh_continuous_aggregate('cond_1', 0, 1);
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
WHERE materialization_id = :cond_1_id
ORDER BY 1,2,3;
SELECT * FROM cagg_invals
WHERE cagg_id = :cond_1_id;
cagg_id | start | end
---------+----------------------+---------------------
6 | -9223372036854775808 | -2
@ -845,12 +777,8 @@ ORDER BY 1,2;
(1 row)
-- Should leave one invalidation on each side of the refresh window
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
WHERE materialization_id = :cond_1_id
ORDER BY 1,2,3;
SELECT * FROM cagg_invals
WHERE cagg_id = :cond_1_id;
cagg_id | start | end
---------+-------+---------------------
6 | 0 | 0
@ -978,12 +906,8 @@ ORDER BY 1,2;
-- Should not have processed invalidations beyond the invalidation
-- threshold.
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
WHERE materialization_id = :thresh_cagg_id
ORDER BY 1,2,3;
SELECT * FROM cagg_invals
WHERE cagg_id = :thresh_cagg_id;
cagg_id | start | end
---------+----------------------+---------------------
8 | -9223372036854775808 | -1
@ -1089,12 +1013,8 @@ ORDER BY 1,2;
(1 row)
-- The aggregate remains invalid beyond the invalidation threshold
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
WHERE materialization_id = :thresh_cagg_id
ORDER BY 1,2,3;
SELECT * FROM cagg_invals
WHERE cagg_id = :thresh_cagg_id;
cagg_id | start | end
---------+----------------------+---------------------
8 | -9223372036854775808 | -1
@ -1170,12 +1090,8 @@ INSERT INTO conditions VALUES(4, 1, 1.0);
INSERT INTO conditions VALUES(6, 1, 1.0);
CALL refresh_continuous_aggregate('cond_1', 10, NULL);
NOTICE: continuous aggregate "cond_1" is already up-to-date
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
WHERE materialization_id = :cond_1_id
ORDER BY 1,2,3;
SELECT * FROM cagg_invals
WHERE cagg_id = :cond_1_id;
cagg_id | start | end
---------+-------+---------------------
6 | 1 | 4

View File

@ -86,6 +86,19 @@ ORDER BY 1 DESC, 2;
SELECT * FROM measure_10
ORDER BY 1 DESC, 2;
CREATE VIEW hyper_invals AS
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
CREATE VIEW cagg_invals AS
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
-- Must refresh to move the invalidation threshold, or no
-- invalidations will be generated. Initially, there is no threshold
@ -95,8 +108,7 @@ ORDER BY 1,2;
-- There should be only "infinite" invalidations in the cagg
-- invalidation log:
SELECT * FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- Now refresh up to 50, and the threshold should be updated accordingly:
CALL refresh_continuous_aggregate('cond_10', 1, 50);
@ -104,8 +116,7 @@ SELECT * FROM _timescaledb_catalog.continuous_aggs_invalidation_threshold
ORDER BY 1,2;
-- Invalidations should be cleared for the refresh window:
SELECT * FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- Refreshing below the threshold does not move it:
CALL refresh_continuous_aggregate('cond_10', 20, 49);
@ -114,36 +125,24 @@ ORDER BY 1,2;
-- Nothing changes with invalidations either since the region was
-- already refreshed and no new invalidations have been generated:
SELECT * FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- Refreshing measure_10 moves the threshold only for the other hypertable:
CALL refresh_continuous_aggregate('measure_10', 1, 30);
SELECT * FROM _timescaledb_catalog.continuous_aggs_invalidation_threshold
ORDER BY 1,2;
SELECT * FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- Refresh on the second continuous aggregate, cond_20, on the first
-- hypertable moves the same threshold as when refreshing cond_10:
CALL refresh_continuous_aggregate('cond_20', 60, 100);
SELECT * FROM _timescaledb_catalog.continuous_aggs_invalidation_threshold
ORDER BY 1,2;
SELECT * FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- There should be no hypertable invalidations initially:
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
SELECT * FROM cagg_invals;
-- Create invalidations across different ranges. Some of these should
-- be deleted and others cut in different ways when a refresh is
@ -156,22 +155,14 @@ INSERT INTO conditions VALUES (10, 5, 23.8), (19, 3, 23.6);
INSERT INTO conditions VALUES (60, 3, 23.7), (70, 4, 23.7);
-- Should see some invaliations in the hypertable invalidation log:
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
-- Generate some invalidations for the other hypertable
INSERT INTO measurements VALUES (20, 4, 23.7);
INSERT INTO measurements VALUES (30, 5, 23.8), (80, 3, 23.6);
-- Should now see invalidations for both hypertables
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
-- First refresh a window where we don't have any invalidations. This
-- allows us to see only the copying of the invalidations to the per
@ -184,17 +175,8 @@ ORDER BY 1,2;
-- Invalidations should be moved from the hypertable invalidation log
-- to the continuous aggregate log, but only for the hypertable that
-- the refreshed aggregate belongs to:
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
SELECT * FROM cagg_invals;
-- Now add more invalidations to test a refresh that overlaps with them.
-- Entries that should be deleted:
@ -214,56 +196,32 @@ INSERT INTO conditions VALUES (60, 3, 23.6), (90, 3, 23.6);
INSERT INTO conditions VALUES (20, 5, 23.8), (100, 3, 23.6);
-- New invalidations in the hypertable invalidation log:
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
-- But nothing has yet changed in the cagg invalidation log:
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- Refresh to process invalidations for daily temperature:
CALL refresh_continuous_aggregate('cond_10', 20, 60);
-- Invalidations should be moved from the hypertable invalidation log
-- to the continuous aggregate log.
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
-- Only the cond_10 cagg should have its entries cut:
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- Refresh also cond_20:
CALL refresh_continuous_aggregate('cond_20', 20, 60);
-- The cond_20 cagg should also have its entries cut:
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- Refresh cond_10 to completely remove an invalidation:
CALL refresh_continuous_aggregate('cond_10', 1, 20);
-- The 1-19 invalidation should be deleted:
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- Clear everything between 0 and 100 to make way for new
-- invalidations
@ -275,11 +233,7 @@ INSERT INTO conditions VALUES (30, 1, 23.4), (46, 1, 23.4);
CALL refresh_continuous_aggregate('cond_10', 1, 40);
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- Refresh whithout cutting (in area where there are no
-- invalidations). Merging of overlapping entries should still happen:
@ -287,26 +241,13 @@ INSERT INTO conditions VALUES (15, 1, 23.4), (42, 1, 23.4);
CALL refresh_continuous_aggregate('cond_10', 90, 100);
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
-- Test max refresh window
CALL refresh_continuous_aggregate('cond_10', NULL, NULL);
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
ORDER BY 1,2,3;
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM cagg_invals;
SELECT * FROM hyper_invals;
-- TRUNCATE the hypertable to invalidate all its continuous aggregates
TRUNCATE conditions;
@ -315,11 +256,7 @@ TRUNCATE conditions;
SELECT * FROM conditions;
-- Should see an infinite invalidation entry for conditions
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
-- Aggregates still hold data
SELECT * FROM cond_10
@ -407,11 +344,7 @@ WHERE user_view_name = 'cond_1' \gset
-- Test invalidations with bucket size 1
INSERT INTO conditions VALUES (0, 1, 1.0);
SELECT hypertable_id AS hyper_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_hypertable_invalidation_log
ORDER BY 1,2,3;
SELECT * FROM hyper_invals;
-- Refreshing around the bucket should not update the aggregate
CALL refresh_continuous_aggregate('cond_1', -1, 0);
@ -424,12 +357,8 @@ ORDER BY 1,2;
-- Refresh only the invalidated bucket
CALL refresh_continuous_aggregate('cond_1', 0, 1);
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
WHERE materialization_id = :cond_1_id
ORDER BY 1,2,3;
SELECT * FROM cagg_invals
WHERE cagg_id = :cond_1_id;
SELECT * FROM cond_1
ORDER BY 1,2;
@ -489,12 +418,8 @@ SELECT * FROM cond_1
ORDER BY 1,2;
-- Should leave one invalidation on each side of the refresh window
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
WHERE materialization_id = :cond_1_id
ORDER BY 1,2,3;
SELECT * FROM cagg_invals
WHERE cagg_id = :cond_1_id;
-- Refresh the two remaining invalidations
CALL refresh_continuous_aggregate('cond_1', 0, 1);
@ -581,12 +506,8 @@ ORDER BY 1,2;
-- Should not have processed invalidations beyond the invalidation
-- threshold.
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
WHERE materialization_id = :thresh_cagg_id
ORDER BY 1,2,3;
SELECT * FROM cagg_invals
WHERE cagg_id = :thresh_cagg_id;
-- Check that things are properly materialized
SELECT * FROM thresh_2
@ -641,12 +562,8 @@ WHERE hypertable_id = :thresh_hyper_id
ORDER BY 1,2;
-- The aggregate remains invalid beyond the invalidation threshold
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
WHERE materialization_id = :thresh_cagg_id
ORDER BY 1,2,3;
SELECT * FROM cagg_invals
WHERE cagg_id = :thresh_cagg_id;
----------------------------------------------------------------------
-- Test that dropping a chunk invalidates the dropped region. First
@ -695,9 +612,5 @@ INSERT INTO conditions VALUES(4, 1, 1.0);
INSERT INTO conditions VALUES(6, 1, 1.0);
CALL refresh_continuous_aggregate('cond_1', 10, NULL);
SELECT materialization_id AS cagg_id,
lowest_modified_value AS start,
greatest_modified_value AS end
FROM _timescaledb_catalog.continuous_aggs_materialization_invalidation_log
WHERE materialization_id = :cond_1_id
ORDER BY 1,2,3;
SELECT * FROM cagg_invals
WHERE cagg_id = :cond_1_id;