diff --git a/timescaledb/how-to-guides/backup-and-restore/pg-dump-and-restore.md b/timescaledb/how-to-guides/backup-and-restore/pg-dump-and-restore.md index cd02bdeaea85..dfdd9f69aebb 100644 --- a/timescaledb/how-to-guides/backup-and-restore/pg-dump-and-restore.md +++ b/timescaledb/how-to-guides/backup-and-restore/pg-dump-and-restore.md @@ -1,17 +1,16 @@ -# Logical backups with `pg_dump` and `pg_restore` [](pg_dump-pg_restore) - -You can backup and restore an [entire database](#backup-entiredb) -or [individual hypertables](#backup-hypertable) using the native PostgreSQL -[`pg_dump`][pg_dump] and [`pg_restore`][pg_restore] commands. +# Logical backups with pg_dump and pg_restore +You can backup and restore an entire database or individual hypertables using +the native PostgreSQL [`pg_dump`][pg_dump] and [`pg_restore`][pg_restore] +commands. Upgrades between different versions of TimescaleDB can be done in place; you -don't need to backup and restore your data. See the [upgrading -instructions][timescaledb-upgrade]. +don't need to backup and restore your data. See +the [upgrading instructions][timescaledb-upgrade]. If you are using this `pg_dump` backup method regularly, make sure you keep track of which versions of PostgreSQL and TimescaleDB you are running. For more -information, see [troubleshooting version mismatches](#tshoot-version-mismatch). +information, see "Troubleshooting version mismatches" in this section. ## Back up your entire database [](backup-entiredb) diff --git a/timescaledb/how-to-guides/compression/compression.md b/timescaledb/how-to-guides/compression/compression.md index 19a318cb8820..5d325ff98d99 100644 --- a/timescaledb/how-to-guides/compression/compression.md +++ b/timescaledb/how-to-guides/compression/compression.md @@ -27,11 +27,7 @@ to incorporate the `segmentby` and `orderby` parameters during compression. This section explains how to enable native compression, and then goes into detail on the most important settings for compression, to help you get the -best possible compression ratio: - -* [Choosing the interval](#compression-interval) after which to compress. -* [Setting the `compress_segmentby`](#compression-segmentby) option appropriately. -* [Choosing a `compress_orderby` column](#compression-orderby) to potentially enhance query efficiency. +best possible compression ratio. ## Enable compression [](compression-enable) You can enable compression on individual hypertables, by declaring which column @@ -60,10 +56,9 @@ compressed. ## Compression policy intervals [](compression-interval) Data is usually compressed after an interval of time has elapsed, and not -immediately. In the ["Enabling compression" procedure](#compression-enable), we -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. +immediately. In the "Enabling compression" procedure, we 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 From our research and experience we know that when data is newly ingested, the @@ -101,7 +96,8 @@ data that is out of order. You can manually decompress a chunk to modify it if you need to. For more -information on how to do that, see [decompressing chunks][decompress-chunks]. +information on how to do that, +see [decompressing chunks](/how-to-guides/compression/decompress-chunks). ### Compression states over time @@ -159,7 +155,7 @@ The `segmentby` columns are useful, but can be overused. If you specify a lot of `segmentby` columns, the number of items in each compressed column is reduced, and compression is not as effective. A good guide is for each segment to contain at least 100 rows per chunk. To achieve this, you might also need to use -the [`compress_orderby` column](#compression-orderby). +the `compress_orderby` column. ## Order entries [](compression-orderby) By default, the items inside a compressed array are arranged in descending order @@ -214,5 +210,3 @@ of any `orderby` column. This way, the query executor looks at this additional column that specifies the range of values in the compressed column, without first performing any decompression, in order to determine whether the row could possibly match a time predicate specified by the query. - -[decompress-chunks]: /how-to-guides/compression/decompress-chunks diff --git a/timescaledb/overview/release-notes/changes-in-timescaledb-2.md b/timescaledb/overview/release-notes/changes-in-timescaledb-2.md index 5565fd35aa3c..0c7b32285748 100644 --- a/timescaledb/overview/release-notes/changes-in-timescaledb-2.md +++ b/timescaledb/overview/release-notes/changes-in-timescaledb-2.md @@ -398,12 +398,12 @@ dropped due to a data retention policy as discussed in the previous section. In TimescaleDB 2.0, views surrounding continuous aggregates (and other policies) have been simplified and generalized. #### Changes and additions -* [`timescaledb_information.continuous_aggregates`](/api/:currentVersion:/informational-views/continuous_aggregate): +* [`timescaledb_information.continuous_aggregates`](/api/latest/continuous_aggregates): now provides information related to the materialized view, which includes the view name and owner, the real time aggregation flag, the materialization and the view definition (the select statement defining the view). -* [`timescaledb_information.jobs`](/api/:currentVersion:/informational-views/jobs): displays information for +* [`timescaledb_information.jobs`](/api/latest/informational-views/jobs): displays information for all policies including continuous aggregates. -* [`timescaledb_information.job_stats`](/api/:currentVersion:/informational-views/jobs_stats): displays job +* [`timescaledb_information.job_stats`](/api/latest/informational-views/job_stats): displays job statistics related to all jobs. #### Removed @@ -490,7 +490,7 @@ or action-specific settings. * [`delete_job`](/api/:currentVersion:/actions/delete_job): Removes the job from the scheduler. This is equivalent to functions that remove policies for built-in actions (e.g., `remove_retention_policy`). * [`timescaledb_information.jobs`](/api/:currentVersion:/informational-views/jobs): The new view provides all job settings available, and it replaces all policy-specific views. -* [`timescaledb_information.jobs_stats`](/api/:currentVersion:/informational-views/jobs_stats): The view presents statistics of executing jobs for policies and actions. +* [`timescaledb_information.jobs_stats`](/api/latest/informational-views/job_stats): The view presents statistics of executing jobs for policies and actions. ## License information [](license-changes)