5933c1785e
This change will make `create_distributed_hypertable` attach only those data nodes that the creating user has USAGE permission on instead of trying to attach all data nodes (even when permissions do not allow it). This prevents an ERROR when a user tries to create a distributed hypertable and lacks USAGE on one or more data nodes. This new behavior *only* applies when no explicit set of data nodes is specified. When an explicit set is specified the behavior remains unchanged, i.e., USAGE is required on all the explicitly specified data nodes. Note that, with distributed hypertables, USAGE permission on a data node (foreign server) only governs the ability to attach it to a hypertable. This is analogous to the regular behavior of foreign servers where USAGE governs who can create foreign tables using the server. The actual usage of the server once associated with a table is not affected as that would break the table if permissions are revoked. The new behavior introduced with this change makes it simpler to use `create_distributed_hypertable` in a multi-user and multi-permission environment where users have different permissions on data nodes (DNs). For instance, imagine user A being allowed to attach DN1 and DN2, while user B can attach DN2 and DN3. Without this change, `create_distributed_hypertable` will always fail since it tries to attach DN1, DN2, and DN3 irrespective of the user that calls the function. Even worse, if only DN1 and DN2 existed initially, user A would be able to create distributed hypertables without errors, but, as soon as DN3 is added, `create_distributed_hypertable` would start to fail for user A. The only way to avoid the above described errors when creating distributed hypertables is for users to pass an explicit set of data nodes that only includes the data nodes they have USAGE on. If a user is forced to do that, the result would in any case be the same as that introduced with this change. Unfortunately, users currently have no way of knowing which data nodes they have USAGE on unless they query the PostgreSQL catalogs. In many cases, a user might not even care about the data nodes they are using if they aren't DBAs themselves. To summarize the new behavior: * If public (everyone) has USAGE on all data nodes, there is no change in behavior. * If a user has USAGE on a subset of data nodes, it will by default attach only those data nodes since it cannot attach the other ones anyway. * If the user specifies an explicit set of data nodes to attach, all of those nodes still require USAGE permissions. (Behavior unchanged.)
| Linux/macOS | Windows | Coverity | Code Coverage |
|---|---|---|---|
 |
 |
 |
TimescaleDB
TimescaleDB is an open-source database designed to make SQL scalable for time-series data. It is engineered up from PostgreSQL and packaged as a PostgreSQL extension, providing automatic partitioning across time and space (partitioning key), as well as full SQL support.
Timescale Cloud is our fully managed, hosted version of TimescaleDB, available in the cloud of your choice (pay-as-you-go, with free trial credits to start). To determine which option is best for you, see Timescale Products for more information about our Apache-2 version, TimescaleDB Community (self-hosted) and Timescale Cloud (hosted), including: feature comparisons, FAQ, documentation, and support.
Below is an introduction to TimescaleDB. For more information, please check out these other resources:
For reference and clarity, all code files in this repository reference
licensing in their header (either Apache License, Version 2.0 or Timescale
License
(TSL)). Apache-2
licensed binaries can be built by passing -DAPACHE_ONLY=1 to bootstrap.
(To build TimescaleDB from source, see instructions in Building from source.)
Using TimescaleDB
TimescaleDB scales PostgreSQL for time-series data via automatic partitioning across time and space (partitioning key), yet retains the standard PostgreSQL interface.
In other words, TimescaleDB exposes what look like regular tables, but are actually only an abstraction (or a virtual view) of many individual tables comprising the actual data. This single-table view, which we call a hypertable, is comprised of many chunks, which are created by partitioning the hypertable's data in either one or two dimensions: by a time interval, and by an (optional) "partition key" such as device id, location, user id, etc. (Architecture discussion)
Virtually all user interactions with TimescaleDB are with hypertables. Creating tables and indexes, altering tables, inserting data, selecting data, etc., can (and should) all be executed on the hypertable.
From the perspective of both use and management, TimescaleDB just looks and feels like PostgreSQL, and can be managed and queried as such.
Before you start
PostgreSQL's out-of-the-box settings are typically too conservative for modern
servers and TimescaleDB. You should make sure your postgresql.conf
settings are tuned, either by using timescaledb-tune
or doing it manually.
Creating a hypertable
-- Do not forget to create timescaledb extension
CREATE EXTENSION timescaledb;
-- We start by creating a regular SQL table
CREATE TABLE conditions (
time TIMESTAMPTZ NOT NULL,
location TEXT NOT NULL,
temperature DOUBLE PRECISION NULL,
humidity DOUBLE PRECISION NULL
);
-- Then we convert it into a hypertable that is partitioned by time
SELECT create_hypertable('conditions', 'time');
Inserting and querying data
Inserting data into the hypertable is done via normal SQL commands:
INSERT INTO conditions(time, location, temperature, humidity)
VALUES (NOW(), 'office', 70.0, 50.0);
SELECT * FROM conditions ORDER BY time DESC LIMIT 100;
SELECT time_bucket('15 minutes', time) AS fifteen_min,
location, COUNT(*),
MAX(temperature) AS max_temp,
MAX(humidity) AS max_hum
FROM conditions
WHERE time > NOW() - interval '3 hours'
GROUP BY fifteen_min, location
ORDER BY fifteen_min DESC, max_temp DESC;
In addition, TimescaleDB includes additional functions for time-series
analysis that are not present in vanilla PostgreSQL. (For example, the time_bucket function above.)
Installation
TimescaleDB is available pre-packaged for several platforms:
Timescale Cloud (database-as-a-service) is available via free trial. You create database instances in the cloud of your choice and use TimescaleDB to power your queries, automating common operational tasks and reducing management overhead.
We recommend following our detailed installation instructions.
To build from source, see instructions here.
Resources
Useful tools
- timescaledb-tune: Helps set your PostgreSQL configuration settings based on your system's resources.
- timescaledb-parallel-copy:
Parallelize your initial bulk loading by using PostgreSQL's
COPYacross multiple workers.
Additional documentation
- Why use TimescaleDB?
- Migrating from PostgreSQL
- Writing data
- Querying and data analytics
- Tutorials and sample data
Community & help
- Slack Channel
- Github Issues
- Timescale Support: see support options (community & subscription)
Releases & updates
- Timescale Release Notes & Future Plans: see planned and in-progress updates and detailed information about current and past releases.
- Subscribe to Timescale Release Notes to get notified about new releases, fixes, and early access/beta programs.