Create Overview

_partials/_architecture-overview.md

@@ -0,0 +1 @@
+FIXME

_partials/_caggs-next.md

@@ -0,0 +1,18 @@
+Creating a continuous aggregate is a two-step process. You need to create the
+view first, then enable a policy to keep the view refreshed. You can create the
+view on a hypertable, or on top of another continuous aggregate. You can have
+more than one continuous aggregate on each source table or view.
+
+Continuous aggregates require a `time_bucket` on the time partitioning column of
+the hypertable.
+
+By default, views are automatically refreshed. You can adjust this by setting
+the [WITH NO DATA](#using-the-with-no-data-option) option. Additionally, the
+view can not be a [security barrier view][postgres-security-barrier].
+
+Continuous aggregates use hypertables in the background, which means that they
+also use chunk time intervals. By default, the continuous aggregate's chunk time
+interval is 10 times what the original hypertable's chunk time interval is. For
+example, if the original hypertable's chunk time interval is 7 days, the
+continuous aggregates that are on top of it have a 70 day chunk time
+interval.

_partials/_compression-next.md

@@ -0,0 +1,21 @@
+Research has shown that when data is newly ingested, the queries are more likely
+to be shallow in time, and wide in columns. Generally, they are debugging
+queries, or queries that cover the whole system, rather than specific, analytic
+queries. An example of the kind of query more likely for new data is "show the
+current CPU usage, disk usage, energy consumption, and I/O for a particular
+server". When this is the case, the uncompressed data has better query
+performance, so the native PostgreSQL row-based format is the best option.
+
+However, as data ages, queries are likely to change. They become more
+analytical, and involve fewer columns. An example of the kind of query run on
+older data is "calculate the average disk usage over the last month." This type
+of query runs much faster on compressed, columnar data.
+
+To take advantage of this and increase your query efficiency, you want to run
+queries on new data that is uncompressed, and on older data that is compressed.
+Setting the right compression policy interval means that recent data is ingested
+in an uncompressed, row format for efficient shallow and wide queries, and then
+automatically converted to a compressed, columnar format after it ages and is
+more likely to be queried using deep and narrow queries. Therefore, one
+consideration for choosing the age at which to compress the data is when your
+query patterns change from shallow and wide to deep and narrow.

_partials/_data-tiering-intro.md

@@ -0,0 +1,6 @@
+Timescale includes traditional disk storage, and a low-cost object-storage
+layer built on Amazon S3. You can move your hypertable data across the different
+storage tiers to get the best price performance. You can use primary storage for
+data that requires quick access, and low-cost object storage for historical
+data. Regardless of where your data is stored, you can query it with standard
+SQL.

_partials/_data-tiering-next.md

@@ -0,0 +1,17 @@
+Data tiering works by periodically and asynchronously moving older chunks to S3
+storage. There, it's stored in the Apache Parquet format, which is a compressed
+columnar format well-suited for S3. Data remains accessible both during and
+after migration.
+
+When you run regular SQL queries, a behind-the-scenes process transparently
+pulls data from wherever it's located: disk storage, object storage, or both.
+Various SQL optimizations limit what needs to be read from S3:
+
+*   Chunk exclusion avoids processing chunks that fall outside the query's time
+    window
+*   The database uses metadata about row groups and columnar offsets, so only
+    part of an object needs to be read from S3
+
+The result is transparent queries across standard PostgreSQL storage and S3
+storage, so your queries fetch the same data as before, with minimal added
+latency.

_partials/_elastic-compute-intro.md

@@ -0,0 +1 @@
+FIXME

_partials/_hypertables-next.md

@@ -0,0 +1,20 @@
+When you create and use a hypertable, it automatically partitions data by time,
+and optionally by space.
+
+Each hypertable is made up of child tables called chunks. Each chunk is assigned
+a range of time, and only contains data from that range. If the hypertable is
+also partitioned by space, each chunk is also assigned a subset of the space
+values.
+
+Each chunk of a hypertable only holds data from a specific time range. When you
+insert data from a time range that doesn't yet have a chunk, Timescale
+automatically creates a chunk to store it.
+
+By default, each chunk covers 7 days. You can change this to better suit your
+needs. For example, if you set `chunk_time_interval` to 1 day, each chunk stores
+data from the same day. Data from different days is stored in different chunks.
+
+<img class="main-content__illustration"
+src="https://assets.timescale.com/docs/images/getting-started/hypertables-chunks.webp"
+alt="A normal table compared to a hypertable. The normal table holds data for 3 different days in one container. The hypertable contains 3 containers, called chunks, each of which holds data for a separate day."
+/>

_partials/_time-bucket-intro.md

@@ -0,0 +1,22 @@
+The [`time_bucket`][time_bucket] function allows you to aggregate data 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.
+
+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
+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].
+
+Time bucketing groups data into time intervals. With `time_bucket`, the interval
+length can be any number of microseconds, milliseconds, seconds, minutes, hours,
+days, weeks, months, years, or centuries.
+
+The `time_bucket` function is usually used in combination with `GROUP BY` to
+aggregate data. For example, you can calculate the average, maximum, minimum, or
+sum of values within a bucket.
+
+<img class="main-content__illustration"
+    src="https://assets.timescale.com/docs/images/getting-started/time-bucket.webp"
+    alt="Diagram showing time-bucket aggregating data into daily buckets, and calculating the daily sum of a value"
+/>

_partials/_timescale-intro.md

@@ -1,2 +1,9 @@
-Timescale extends PostgreSQL for time-series and analytics, so you can build
-faster, scale further, and stay under budget.
+Timescale is a database platform engineered to deliver speed and scale to
+resource-intensive workloads, which makes it great for things like time series,
+event, and analytics data. Timescale is built on PostgreSQL, so you have access
+to the entire PostgreSQL ecosystem, with a user-friendly interface that
+simplifies database deployment and management. Timescale dramatically improves
+your database performance with hypertables and continuous aggregates, and can
+save you money with features like compression, usage-based storage, and data
+tiering. And the Timescale expert support team is available to assist at no
+extra charge 24 hours a day, 7 days a week, 365 days a year.

_partials/_timescale-value-prop.md

@@ -0,0 +1,10 @@
+Timescale works for you end-to-end. Converting your PostgreSQL tables to
+hypertables instantly improves query and insert performance, and gives you
+immediate access to continuous aggregates and compression. Continuous aggregates
+continuously and incrementally materialize your aggregate queries, giving you
+updated insights as soon as new data arrives. Compression immediately improves
+database performance and, with usage-based storage, also saves you money. Pair
+all this with data tiering to automatically archive older data, saving money,
+but retaining access when you need it. Need to know more? Keep reading, and
+remember a world-class support team is here to help you if you need it, every
+step of the way.

overview/index.md

@@ -0,0 +1,106 @@
+---
+title: Timescale overview
+excerpt: Learn about core Timescale concepts, architecture, and features
+products: [cloud, mst, self_hosted]
+keywords: [learn, architecture, hypertables, time buckets, compression, continuous aggregates]
+---
+
+import CaggsIntro from "versionContent/_partials/_caggs-intro.mdx";
+import CaggsTypes from "versionContent/_partials/_caggs-types.mdx";
+import CaggsNext from "versionContent/_partials/_caggs-next.mdx";
+import CloudIntro from "versionContent/_partials/_cloud-intro.mdx";
+import HypertablesIntro from "versionContent/_partials/_hypertables-intro.mdx";
+import HypertablesNext from "versionContent/_partials/_hypertables-next.mdx";
+import TimeSeriesIntro from "versionContent/_partials/_timeseries-intro.mdx";
+import TimescaleIntro from "versionContent/_partials/_timescale-intro.mdx";
+import TimescaleValueProp from "versionContent/_partials/_timescale-value-prop.mdx";
+import CompressionIntro from "versionContent/_partials/_compression-intro.mdx";
+import CompressionNext from "versionContent/_partials/_compression-next.mdx";
+import UbsIntro from "versionContent/_partials/_usage-based-storage-intro.mdx";
+import ElasticComputeIntro from "versionContent/_partials/_elastic-compute-intro.mdx";
+import DataTieringIntro from "versionContent/_partials/_data-tiering-intro.mdx";
+import DataTieringNext from "versionContent/_partials/_data-tiering-next.mdx";
+import Architecture from "versionContent/_partials/_architecture-overview.mdx";
+import TimeBucketIntro from "versionContent/_partials/_time-bucket-intro.mdx";
+
+# Timescale overview
+
+<TimescaleIntro />
+
+<TimescaleValueProp />
+
+This section provides an overview of Timescale architecture, introducing you
+to special Timescale concepts and features.
+
+## Time-series data
+
+<TimeSeriesIntro />
+
+## Timescale architecture
+
+<Architecture />
+
+## Timescale
+
+<CloudIntro />
+
+## Hypertables
+
+<HypertablesIntro />
+
+<HypertablesNext />
+
+For more information about hypertables, see the
+[hypertables section][hypertables]
+
+## Time buckets
+
+<TimeBucketIntro />
+
+For more information about time bucketing, see the
+[time buckets section][time-buckets]
+
+## Data tiering
+
+<DataTieringIntro />
+
+<DataTieringNext />
+
+For more information about data tiering, see the
+[data tiering section][data-tiering]
+
+## Continuous aggregation
+
+<CaggsIntro />
+
+<CaggsTypes />
+
+<CaggsNext />
+
+For more information about continuous aggregation, see the
+[continuous aggregates section][caggs]
+
+## Compression
+
+<CompressionIntro />
+
+<CompressionNext />
+
+For more information about compression, see the
+[compression section][time-buckets]
+
+## Elastic compute and usage-based storage
+
+<UbsIntro />
+
+<ElasticComputeIntro />
+
+For more information about elastic compute and usage-based storage, see the
+[billing section][billing]
+
+[hypertables]: /use-timescale/:currentVersion:/hypertables/
+[time-buckets]: /use-timescale/:currentVersion:/time-buckets/
+[data-tiering]: /use-timescale/:currentVersion:/data-tiering/
+[caggs]: /use-timescale/:currentVersion:/continuous-aggregates/
+[time-buckets]: /use-timescale/:currentVersion:/time-buckets/
+[billing]: /use-timescale/:currentVersion:/account-management/

overview/page-index/page-index.js

@@ -0,0 +1,9 @@
+module.exports = [
+  {
+    title: "What is Timescale?",
+    href: "overview",
+    filePath: "index.md",
+    excerpt:
+      "What is Timescale?",
+  },
+];

page-index/page-index.js

@@ -7,8 +7,11 @@ const navigationPageIndex = require("../navigation/page-index/page-index");
 const tutorialsPageIndex = require("../tutorials/page-index/page-index.js");
 const codeQuickStartsPageIndex = require("../quick-start/page-index/page-index.js");
 const timescaleAboutPageIndex = require("../about/page-index/page-index");
+const overviewPageIndex = require("../overview/page-index/page-index");
+
 
 module.exports = [
+  ...overviewPageIndex,
   ...gsgPageIndex,
   ...timescaleUsingPageIndex,
   ...tutorialsPageIndex,

use-timescale/compression/about-compression.md

@@ -7,6 +7,8 @@ keywords: [compression, hypertables]
 
 import CompressionIntro from 'versionContent/_partials/_compression-intro.mdx';
 
+import CompressionNext from "versionContent/_partials/_compression-next.mdx";
+
 # About compression
 
 <CompressionIntro />
@@ -104,33 +106,13 @@ compression.
 ## Compression policy intervals
 
 Data is usually compressed after an interval of time, and not
-immediately. In the "Enabling compression" procedure, you used a seven day
+immediately. In the example in this section, you used a seven day
 compression interval. Choosing a good compression interval can make your queries
 more efficient, and also allow you to handle data that is out of order.
 
 ### Query efficiency
 
-Research has shown that when data is newly ingested, the queries are more likely
-to be shallow in time, and wide in columns. Generally, they are debugging
-queries, or queries that cover the whole system, rather than specific, analytic
-queries. An example of the kind of query more likely for new data is "show the
-current CPU usage, disk usage, energy consumption, and I/O for a particular
-server". When this is the case, the uncompressed data has better query
-performance, so the native PostgreSQL row-based format is the best option.
-
-However, as data ages, queries are likely to change. They become more
-analytical, and involve fewer columns. An example of the kind of query run on
-older data is "calculate the average disk usage over the last month." This type
-of query runs much faster on compressed, columnar data.
-
-To take advantage of this and increase your query efficiency, you want to run
-queries on new data that is uncompressed, and on older data that is compressed.
-Setting the right compression policy interval means that recent data is ingested
-in an uncompressed, row format for efficient shallow and wide queries, and then
-automatically converted to a compressed, columnar format after it ages and is
-more likely to be queried using deep and narrow queries. Therefore, one
-consideration for choosing the age at which to compress the data is when your
-query patterns change from shallow and wide to deep and narrow.
+<CompressionNext />
 
 ### Modified data
 

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

@@ -78,7 +78,8 @@ WHERE t1.id IN (1, 2, 3, 4)
 GROUP BY ...
 ```
 
-`INNER JOIN` on a single equality condition specified in `WHERE` clause, this is allowed but not recommended:
+`INNER JOIN` on a single equality condition specified in `WHERE` clause, this is
+allowed but not recommended:
 
 ```sql
 CREATE MATERIALIZED VIEW my_view WITH (timescaledb.continuous) AS
@@ -99,7 +100,8 @@ JOIN table_2 t2 ON t1.t2_id = t2.id AND t1.t2_id_2 = t2.id
 GROUP BY ...
 ```
 
-A `JOIN` with a single equality condition specified in `WHERE` clause cannot be combined with further conditions in the `WHERE` clause.
+A `JOIN` with a single equality condition specified in `WHERE` clause cannot be
+combined with further conditions in the `WHERE` clause.
 
 ```sql
 CREATE MATERIALIZED VIEW my_view WITH (timescaledb.continuous) AS

use-timescale/continuous-aggregates/create-a-continuous-aggregate.md

@@ -5,26 +5,11 @@ products: [cloud, mst, self_hosted]
 keywords: [continuous aggregates, create]
 ---
 
-# Create continuous aggregates
+import CaggsNext from "versionContent/_partials/_caggs-next.mdx";
 
-Creating a continuous aggregate is a two-step process. You need to create the
-view first, then enable a policy to keep the view refreshed. You can create the
-view on a hypertable, or on top of another continuous aggregate. You can have
-more than one continuous aggregate on each source table or view.
+# Create continuous aggregates
 
-Continuous aggregates require a `time_bucket` on the time partitioning column of
-the hypertable.
-
-By default, views are automatically refreshed. You can adjust this by setting
-the [WITH NO DATA](#using-the-with-no-data-option) option. Additionally, the
-view can not be a [security barrier view][postgres-security-barrier].
-
-Continuous aggregates use hypertables in the background, which means that they
-also use chunk time intervals. By default, the continuous aggregate's chunk time
-interval is 10 times what the original hypertable's chunk time interval is. For
-example, if the original hypertable's chunk time interval is 7 days, the
-continuous aggregates that are on top of it have a 70 day chunk time
-interval.
+<CaggsNext />
 
 ## Create a continuous aggregate