update

_partials/_caggs-intro.md

@@ -1,12 +1,12 @@
-Time-series data usually grows very quickly. And that means that aggregating the
-data into useful summaries can become very slow. Continuous aggregates makes
-aggregating data lightning fast.
+In modern applications, data usually grows very quickly. This means that aggregating 
+it into useful summaries can become very slow. $CLOUD_LONG continuous aggregates make
+aggregating data lightning fast, accurate, and easy. 
 
 If you are collecting data very frequently, you might want to aggregate your
-data into minutes or hours instead. For example, if you have a table of
-temperature readings taken every second, you can find the average temperature
+data into minutes or hours instead. For example, if an IoT device takes 
+temperature readings every second, you might want to find the average temperature
 for each hour. Every time you run this query, the database needs to scan the
-entire table and recalculate the average every time.
+entire table and recalculate the average.
 
 Continuous aggregates are a kind of hypertable that is refreshed automatically
 in the background as new data is added, or old data is modified. Changes to your
@@ -22,9 +22,9 @@ database.
 
 Because continuous aggregates are based on hypertables, you can query them in
 exactly the same way as your other tables, and enable [compression][compression]
-or [tiered storage][data-tiering] on your continuous aggregates. You can even
+or [tiered storage][data-tiering] on them. You can even
 create
-[continuous aggregates on top of your continuous aggregates][hierarchical-caggs].
+[continuous aggregates on top of your continuous aggregates][hierarchical-caggs] - for an even more fine-tuned aggregation. 
 
 By default, querying continuous aggregates provides you with real-time data.
 Pre-aggregated data from the materialized view is combined with recent data that

use-timescale/continuous-aggregates/hierarchical-continuous-aggregates.md

@@ -6,9 +6,9 @@ keywords: [continuous aggregates, hierarchical, create]
 
 # Hierarchical continuous aggregates
 
-You can create continuous aggregates on top of other continuous aggregates. This
-allows you to summarize data at different levels of granularity. For example,
-you might have an hourly continuous aggregate that summarizes minute-by-minute
+The more data you have, the more likely you are to run a more sophisticated analysis on it. When a simple one-level aggregation is not enough, $CLOUD_LONG lets you create continuous aggregates on top of other continuous aggregates. This way, you summarize data at different levels of granularity, while still saving resources with precomputing. 
+
+For example, you might have an hourly continuous aggregate that summarizes minute-by-minute
 data. To get a daily summary, you can create a new continuous aggregate on top
 of your hourly aggregate. This is more efficient than creating the daily
 aggregate on top of the original hypertable, because you can reuse the

use-timescale/continuous-aggregates/index.md

@@ -7,22 +7,20 @@ keywords: [continuous aggregates]
 
 # Continuous aggregates
 
-Continuous aggregates are designed to make queries on very large datasets run
-faster. Timescale continuous aggregates use
-PostgreSQL [materialized views][postgres-materialized-views] to continuously and
-incrementally refresh a query in the background, so that when you run the query,
-only the data that has changed needs to be computed, not the entire dataset.
+From real-time dashboards to performance monitoring and historical trend analysis, data aggregation is a must-have for any sort of analytical application. To address this need, $CLOUD_LONG continuous aggregates precompute and store aggregate data for you. Using PostgreSQL [materialized views][postgres-materialized-views], continuous aggregates incrementally refresh the aggregation query in the background, so that when you do run it, only the data that has changed needs to be computed, not the entire dataset. This means you always have the latest aggregate data at your fingertips - and spend as little resources on it, as possible. 
+
+In this section you:
 
 *   [Learn about continuous aggregates][about-caggs] to understand how it works
     before you begin using it.
 *   [Create a continuous aggregate][cagg-create] and query it.
-*   [Create a continuous aggregate on top of another continuous aggregate][cagg-on-cagg]
+*   [Create a continuous aggregate on top of another continuous aggregate][cagg-on-cagg].
 *   [Add refresh policies][cagg-autorefresh] to an existing continuous aggregate.
 *   [Manage time][cagg-time] in your continuous aggregates.
 *   [Drop data][cagg-drop] from your continuous aggregates.
 *   [Manage materialized hypertables][cagg-mat-hypertables].
 *   [Use real-time aggregates][cagg-realtime].
-*   [Compression with continuous aggregates][cagg-compression].
+*   [Use compression with continuous aggregates][cagg-compression].
 *   [Migrate your continuous aggregates][cagg-migrate] from old to new format.
     Continuous aggregates created in Timescale 2.7 and later are in the new
     format, unless explicitly created in the old format.

use-timescale/continuous-aggregates/real-time-aggregates.md

@@ -7,35 +7,36 @@ keywords: [continuous aggregates, real-time aggregates]
 
 import CaggsRealTimeHistoricalDataRefreshes from 'versionContent/_partials/_caggs-real-time-historical-data-refreshes.mdx';
 
-# Real time aggregates
+# Real-time aggregates
 
-Continuous aggregates do not include the most recent data chunk from the
-underlying hypertable. Real time aggregates use the aggregated data and add the
-most recent raw data to it to provide accurate and up to date results, without
-needing to aggregate data as it is being written. In Timescale versions 1.7 to 2.12,
-real time aggregates are enabled by default; when you create a continuous
+Rapidly growing data means you need more control over what and how to aggregate. With this in mind, $CLOUD_LONG equips you with tools for more fine-tuned data analysis. 
+
+By default, continuous aggregates do not include the most recent data chunk from the
+underlying hypertable. Real-time aggregates, however, use the aggregated data **and** add the
+most recent raw data to it. This provides accurate and up-to-date results, without
+needing to aggregate data as it is being written. 
+
+In Timescale versions 1.7 to 2.12, real-time aggregates are enabled by default; when you create a continuous
 aggregate view, queries to that view include the most recent data, even if
-it has not yet been aggregated. In Timescale 2.13 and later real time aggregates are *DISABLED* by default.
+it has not yet been aggregated. In Timescale 2.13 and later real-time aggregates are *DISABLED* by default.
 
-For more detail on the comparison between continuous and real time aggregates,
+For more detail on the comparison between continuous and real-time aggregates,
 see our [real time aggregate blog post][blog-rtaggs].
 
-## Use real time aggregates
+## Use real-time aggregates
 
-You can enable and disable real time aggregation by setting the
+You can enable and disable real-time aggregation by setting the
 `materialized_only` parameter when you create or alter the view.
 
 <Procedure>
 
-### Using real time aggregation
-
-1.  For an existing table, at the `psql` prompt, disable real time aggregation:
+1.  For an existing table, at the `psql` prompt, disable real-time aggregation:
 
     ```sql
     ALTER MATERIALIZED VIEW table_name set (timescaledb.materialized_only = true);
     ```
 
-1.  Re-enable real time aggregation:
+1.  Re-enable real-time aggregation:
 
     ```sql
     ALTER MATERIALIZED VIEW table_name set (timescaledb.materialized_only = false);

use-timescale/hypertables/improve-query-performance.md

@@ -7,6 +7,7 @@ keywords: [hypertables, indexes, chunks]
 
 # Improve query performance
 
+One of the key purposes of hypertables is to make your analytical queries run with the lowest latency possible - and they have been designed accordingly. 
 When you execute a query on a hypertable, you do not parse the whole table; you only access the chunks necessary
 to satisfy the query. This works well when the `WHERE` clause of a query uses the column by which a hypertable is 
 partitioned. For example, in a hypertable where every day of the year is a separate chunk, a query for September 1 

use-timescale/hypertables/index.md

@@ -7,10 +7,8 @@ keywords: [hypertables]
 
 # Hypertables
 
-Hypertables are PostgreSQL tables with special features that make it easy to
-handle time-series data. Anything you can do with regular PostgreSQL tables, you
-can do with hypertables. In addition, you get the benefits of improved
-performance and user experience for time-series data.
+Hypertables are PostgreSQL tables designed to simplify and accelerate data analysis. Anything you can do with regular PostgreSQL tables, you
+can do with hypertables - but much faster and more conveniently. In this section, you: 
 
 *   [Learn about hypertables][about-hypertables]
 *   [Create a hypertable][create-hypertables]

use-timescale/time-buckets/about-time-buckets.md

@@ -7,19 +7,17 @@ keywords: [time buckets]
 
 # About time buckets
 
-The [`time_bucket`][time_bucket] function allows you to aggregate data in a 
-[hypertable][create-hypertable] into buckets of time. For example: 5 minutes, 1 hour, or 3 days. 
+Time bucketing is essential for real-time analytics. The [`time_bucket`][time_bucket] function allows you to aggregate data in a [hypertable][create-hypertable] into buckets of time. For example, 5 minutes, 1 hour, or 3 days. 
 It's similar to PostgreSQL's [`date_bin`][date_bin] function, but it gives you more
-flexibility in bucket size and start time.
+flexibility in the bucket size and start time.
 
-Time bucketing is essential to working with time-series data. You can use it to
-roll up data for analysis or downsampling. For example, you can calculate
+You can use it to roll up data for analysis or downsampling. For example, you can calculate
 5-minute averages for a sensor reading over the last day. You can perform these
 rollups as needed, or pre-calculate them in [continuous aggregates][caggs].
 
 This section explains how time bucketing works. For examples of the
 `time_bucket` function, see the section on
-[using time buckets][use-time-buckets].
+[Aggregate time-series data with time_bucket][use-time-buckets].
 
 ## How time bucketing works
 

use-timescale/time-buckets/index.md

@@ -10,7 +10,7 @@ keywords: [time buckets]
 Time buckets enable you to aggregate data in [hypertables][create-hypertable] by time interval. For example, you can
 group data into 5-minute, 1-hour, and 3-day buckets to calculate summary values.
 
-*   [Learn how time buckets work][about-time-buckets] in Timescale
+*   [Learn how time buckets work][about-time-buckets] in $CLOUD_LONG
 *   [Use time buckets][use-time-buckets] to aggregate data
 
 [about-time-buckets]: /use-timescale/:currentVersion:/time-buckets/about-time-buckets/

use-timescale/write-data/about-writing-data.md

@@ -12,7 +12,7 @@ Timescale supports writing data in the same way as PostgreSQL, using `INSERT`,
 `UPDATE`, `INSERT ... ON CONFLICT`, and `DELETE`.
 
 <Highlight type="note">
-Because Timescale is a time-series database, hypertables are optimized for
+$CLOUD_LONG is optimized for running real-time analytics workloads on time-series data. For this reason, hypertables are optimized for
 inserts to the most recent time intervals. Inserting data with recent time
 values gives
 [excellent performance](https://www.timescale.com/blog/timescaledb-vs-6a696248104e/).