diff --git a/advocacy_docs/edb-postgres-ai/analytics/external_tables.mdx b/advocacy_docs/edb-postgres-ai/analytics/external_tables.mdx new file mode 100644 index 00000000000..a5c287e359e --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/external_tables.mdx @@ -0,0 +1,66 @@ +--- +title: Querying Delta Lake Tables in S3-compatible object storage +navTitle: External Tables +description: Access and Query data stored as Delta Lake Tablles in S3-compatible object storage using External Tables +deepToC: true +--- + +## Overview + +External tables allow you to access and query data stored in S3-compatible object storage using SQL. You can create an external table that references data in S3-compatible object storage and query the data using standard SQL commands. + +## Prerequisites + +* An EDB Postgres AI account and a Lakehouse node. +* An S3-compatible object storage location with data stored as Delta Lake Tables. + * See [Bringing your own data](reference/loadingdata) for more information on how to prepare your data. +* Credentials to access the S3-compatible object storage location, unless it is a public bucket. + * These credentials will be stored within the database. We recommend creating a separate user with limited permissions for this purpose. + +!!! Note Regions, latency and cost +Using an S3 bucket that isn't in the same region as your node will + +* be slow because of cross-region latencies +* will incur AWS costs (between $0.01 and $0.02 / GB) for data transfer. Currently these egress costs are not passed through to you but we do track them and reserve the right to terminate an instance. +!!! + +## Creating an External Storage Location + +The first step is to create an external storage location which references S3-compatible object storage where your data resides. A storage location is an object within the database which you refer to to access the data; each storage location has a name for this purpose. + +Creating a named storage location is performed with SQL by executing the `pgaa.create_storage_location` function. +`pgaa` is the name of the extension and namespace that provides the functionality to query external storage locations. +The `create_storage_location` function takes a name for the new storage location, and the URI of the S3-compatible object storage location as parameters. +The function optionally can take a third parameter, `options`, which is a JSON object for specifying optional settings, detailed in the [functions reference](reference/functions#pgaacreate_storage_location). +For example, in the options, you can specify the access key ID and secret access key for the storage location to enable access to a private bucket. + +The following example creates an external table that references a public S3-compatible object storage location: + +```sql +SELECT pgaa.create_storage_location('sample-data', 's3://pgaa-sample-data-eu-west-1'); +``` + +The next example creates an external storage location that references a private S3-compatible object storage location: + +```sql +SELECT pgaa.create_storage_location('private-data', 's3://my-private-bucket', '{"access_key_id": "my-access-key-id","secret_access_key": "my-secret-access-key"}'); +``` + +## Creating an External Table + +After creating the external storage location, you can create an external table that references the data in the storage location. +The following example creates an external table that references a Delta Lake Table in the S3-compatible object storage location: + +```sql +CREATE TABLE public.customer () USING PGAA WITH (pgaa.storage_location = 'sample-data', pgaa.path = 'tpch_sf_1/customer'); +``` + +Note that the schema is not defined in the `CREATE TABLE` statement. The pgaa extension expects the schema to be defined in the storage location, and the schema itself is derived from the schema stored at the path specified in the `pgaa.path` option. The pgaa extension will infer the best Postgres-equivalent data types for the columns in the Delta Table. + +## Querying an External Table + +After creating the external table, you can query the data in the external table using standard SQL commands. The following example queries the external table created in the previous step: + +```sql +SELECT COUNT(*) FROM public.customer; +``` diff --git a/advocacy_docs/edb-postgres-ai/analytics/quick_start.mdx b/advocacy_docs/edb-postgres-ai/analytics/quick_start.mdx index df985fb9289..705927681ac 100644 --- a/advocacy_docs/edb-postgres-ai/analytics/quick_start.mdx +++ b/advocacy_docs/edb-postgres-ai/analytics/quick_start.mdx @@ -81,50 +81,33 @@ Persistent data in system tables (users, roles, etc) is stored in an attached block storage device and will survive a restart or backup/restore cycle. * Only Postgres 16 is supported. -For more notes about supported instance sizes, -see [Reference - Supported AWS instances](./reference/#supported-aws-instances). +For more notes about supported instance sizes,see [Reference - Supported AWS instances](./reference/instances). ## Operating a Lakehouse node ### Connect to the node -You can connect to the Lakehouse node with any Postgres client, in the same way -that you connect to any other cluster from EDB Postgres AI Cloud Service -(formerly known as BigAnimal): navigate to the cluster detail page and copy its -connection string. +You can connect to the Lakehouse node with any Postgres client, in the same way that you connect to any other cluster from EDB Postgres AI Cloud Service (formerly known as BigAnimal): navigate to the cluster detail page and copy its connection string. -For example, you might copy the `.pgpass` blob into `~/.pgpass` (making sure to -replace `$YOUR_PASSWORD` with the password you provided when launching the -cluster). Then you can copy the connection string and use it as an argument to -`psql` or `pgcli`. +For example, you might copy the `.pgpass` blob into `~/.pgpass` (making sure to replace `$YOUR_PASSWORD` with the password you provided when launching the cluster). +Then you can copy the connection string and use it as an argument to `psql` or `pgcli`. -In general, you should be able to connect to the database with any Postgres -client. We expect all introspection queries to work, and if you find one that -doesn't, then that's a bug. +In general, you should be able to connect to the database with any Postgres client. +We expect all introspection queries to work, and if you find one that doesn't, then that's a bug. ### Understand the constraints -* Every cluster uses EPAS or PGE. So expect to see boilerplate tables from those -flavors in the installation when you connect. -* Queryable data (like the benchmarking datasets) is stored in object storage -as Delta Tables. Every cluster comes pre-loaded to point to a storage bucket -with benchmarking data inside (TPC-H, TPC-DS, Clickbench) at -scale factors 1 and 10. +* Every cluster uses EPAS or PGE. So expect to see boilerplate tables from those flavors in the installation when you connect. +* Queryable data (like the benchmarking datasets) is stored in object storage as Delta Tables. Every cluster comes pre-loaded to point to a storage bucket with benchmarking data inside (TPC-H, TPC-DS, Clickbench) at scale factors from 1 to 1000. * Only AWS is supported at the moment. Bring Your Own Account (BYOA) is not supported. -* You can deploy a cluster in any region that is activated in -your EDB Postgres AI Account. Each region has a bucket with a copy of the -benchmarking data, and so when you launch a cluster, it will use the -benchmarking data in the location closest to it. -* The cluster is ephemeral. None of the data is stored on the hard drive, -except for data in system tables, e.g. roles and users and grants. -If you restart the cluster, or backup the cluster and then restore it, -it will restore these system tables. But the data in object storage will +* You can deploy a cluster in any region that is activated in your EDB Postgres AI Account. Each region has a bucket with a copy of the +benchmarking data, and so when you launch a cluster, it will use the benchmarking data in the location closest to it. +* The cluster is ephemeral. None of the data is stored on the hard drive, except for data in system tables, e.g. roles and users and grants. +If you restart the cluster, or backup the cluster and then restore it, it will restore these system tables. But the data in object storage will remain untouched. -* The cluster supports READ ONLY queries of the data in object -storage (but it supports write queries to system tables for creating users, +* The cluster supports READ ONLY queries of the data in object storage (but it supports write queries to system tables for creating users, etc.). You cannot write directly to object storage. You cannot create new tables. -* If you want to load your own data into object storage, -see [Reference - Bring your own data](./reference/#advanced-bring-your-own-data). +* If you want to load your own data into object storage, see [Reference - Bring your own data](reference/loadingdata). ## Inspect the benchmark datasets @@ -140,7 +123,7 @@ The available benchmarking datasets are: * 1 Billion Row Challenge For more details on benchmark datasets, -see Reference - Available benchmarking datasets](./reference/#available-benchmarking-datasets). +see Reference - Available benchmarking datasets](./reference/datasets). ## Query the benchmark datasets diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference.mdx deleted file mode 100644 index 848981e983f..00000000000 --- a/advocacy_docs/edb-postgres-ai/analytics/reference.mdx +++ /dev/null @@ -1,302 +0,0 @@ ---- -title: Reference - EDB Postgres Lakehouse -navTitle: Reference -description: Things to know about EDB Postgres Lakehouse -deepToC: true ---- - -Postgres Lakehouse is an early product. Eventually, it will support deployment -modes across multiple clouds and on-premises. However, currently it's fairly -limited in terms of where you can deploy it and what data you can query with it. - -To get the best experience with Postgres Lakehouse, you should follow the -"quick start" guide to query benchmarking data. Then you can try loading your -own data with Lakehouse Sync. If you're intrigued, reach out to us and -we can talk more about your use case and potential opportunities. - -This page details some of the important bits to know. - -## Supported cloud providers and regions - -**AWS only**: Currently, support for all Lakehouse features (Lakehouse nodes, -Managed Storage Locations, and Lakehouse Sync) is limited to AWS. - -**EDB-hosted only**: "Bring Your Own Account" (BYOA) regions are NOT currently -supported for Lakehouse resources. Support is limited to -ONLY **EDB Postgres® AI - Hosted** environments on AWS (a.k.a. "EDB-Hosted AWS regions"). - -This means you can select from one of the following regions: - -* North America - * US East 1 - * US East 2 - * US West 2 -* Europe - * EU Central 1 - * EU West 1 - * EU West 2 -* Asia - * AP South 1 -* Australia - * AP SouthEast 2 - -To be precise: - -* Lakehouse nodes can only be provisioned in EDB-hosted AWS regions -* Managed Storage Locations can only be created in EDB-hosted AWS regions -* Lakehouse Sync can only sync from source databases in EDB-hosted AWS regions - -These limitations will be removed as we continue to improve the product. Eventually, -we will support BYOA, as well as Azure and GCP, for all Lakehouse use cases. We -will also add better support for "external" buckets ("bring your own bucket"). - -## Supported AWS instances - -When deploying a Lakehouse node, you must choose an instance type from -the `m6id` family of instances. Importantly, these instances come with NVMe -drives attached to them. - -**Instances are ephemeral.** These NVMe drives are used only for spill-out space -*while processing queries, and for caching Delta Tables on disk. -All data on the NVMe drives will be lost when the cluster is shutdown. - -**System tables are persisted.** Persistent data in system tables (users, roles, -*etc.) is stored in an attached -block storage device, and will survive a pause/resume cycle. - -**Supported instances** - -| API Name | Memory | vCPUs | Cores | Storage | -| --------------- | --------- | --------- | ----- | ------------------------------- | -| `m6id.large` | 8.0 GiB | 2 vCPUs | 1 | 118 GB NVMe SSD | -| `m6id.xlarge` | 16.0 GiB | 4 vCPUs | 2 | 237 GB NVMe SSD | -| `m6id.2xlarge` | 32.0 GiB | 8 vCPUs | 4 | 474 GB NVMe SSD | -| `m6id.4xlarge` | 64.0 GiB | 16 vCPUs | 8 | 950 GB NVMe SSD | -| `m6id.8xlarge` | 128.0 GiB | 32 vCPUs | 16 | 1900 GB NVMe SSD | -| `m6id.12xlarge` | 192.0 GiB | 48 vCPUs | 24 | 2850 GB (2 \* 1425 GB NVMe SSD) | -| `m6id.16xlarge` | 256.0 GiB | 64 vCPUs | 32 | 3800 GB (2 \* 1900 GB NVMe SSD) | -| `m6id.24xlarge` | 384.0 GiB | 96 vCPUs | 48 | 5700 GB (4 \* 1425 GB NVMe SSD) | -| `m6id.32xlarge` | 512.0 GiB | 128 vCPUs | 64 | 7600 GB (4 \* 1900 GB NVMe SSD) | - -## Available benchmarking datasets - -When you provision a Lakehouse node, it comes pre-configured to point to a public -S3 bucket in its same region, containing sample benchmarking datasets. - -You can query tables in these datasets by referencing them with their schema -name. - -| Schema Name | Dataset | -| --------------- | ---------------------------- | -| `tpcds_sf_1` | TPC-DS, Scale Factor 1 | -| `tpcds_sf_10` | TPC-DS, Scale Factor 10 | -| `tpcds_sf_100` | TPC-DS, Scale Factor 100 | -| `tpcds_sf_1000` | TPC-DS, Scale Factor 1000 | -| `tpch_sf_1` | TPC-H, Scale Factor 1 | -| `tpch_sf_10` | TPC-H, Scale Factor 10 | -| `tpch_sf_100` | TPC-H, Scale Factor 100 | -| `tpch_sf_1000` | TPC-H, Scale Factor 1000 | -| `clickbench` | ClickBench, 100 million rows | -| `brc_1b` | Billion row challenge | - -!!!note Notes about ClickBench data: - -Data columns (`EventData`) are integers, not dates. - -You must quote ClickBench column names, because they contain uppercase letters, -but unquoted identifiers in Postgres are case-insensitive. For example: - -✅ `select "Title" from clickbench.hits;` - -🚫 `select Title from clickbench.hits;` -!!! - -## User management - -When you provision a Lakehouse node, you must provide a password. We do not -save this password. You will need it to login as the `edb_admin` user. This is -not a superuser account, but it does have the ability to create users and roles -and grants. Thus, you can either share the credentials for `edb_admin` itself, -or you can create other users and distribute those. - -## Gotcha: Do not set `search_path` - -Do not set `search_path`. Always reference fully qualified table names. - -Using `search_path` makes Postgres Lakehouse fall back to PostgreSQL, -dramatically impacting query performance. To avoid this, qualify all table names -in your query with a schema. - -For example: - -**🚫 Do NOT do this!** - -```sql ---- DO NOT DO THIS -SET search_path = tpch_sf_10; -SELECT COUNT(*) FROM lineitem; -``` - -**✅ Do this instead!** - -```sql -SELECT COUNT(*) FROM tpch_sf_10.lineitem -``` - -## Supported queries - -In general, **READ ONLY** queries are supported. You cannot write directly to -object storage. This includes all Postgres built-in functions, statements -and types. It also includes any of those provided by EPAS or PGE, depending on -which distribution you choose to deploy. - -In general, you cannot insert, update, delete or otherwise modify data. You -cannot `CREATE TABLE`. You must load data into the bucket out-of-band, either -with your own ETL scripts or with Lakehouse Sync. See "Advanced: Bring Your Own -Data" for more details. (In the future, we will be making this more usable with -a custom DDL). - -One exception is Postgres system tables, such as those used for storing users, -roles, and grants. These tables are stored on the local block device, which is -included in backups and restores. So you can `CREATE USER` or `CREATE ROLE` or -`GRANT USAGE`, and these users/roles/grants will survive restarts and restores. - -## DirectScan vs. fallback modes and EXPLAIN - -Postgres Lakehouse is fastest when it can "push down" your entire query to -DataFusion, the vectorized query used for handling queries when possible. (In the -future, this will be more fine-grained as we add support for partial pushdowns.) - -Postgres Lakehouse can execute your query in two modes. First, it attempts to -run the entire query using Seafowl (a dedicated columnar database based on -DataFusion). If Seafowl can't run the entire query, for example, because it -uses PostgreSQL-specific operations like JSON, then Postgres Lakehouse will fall -back to using the PostgreSQL executor, with Seafowl streaming full table -contents to it. - -If your query is extremely slow, it's possible that's what's happening. - -You can check which mode is being used by running an `EXPLAIN` on the query and -making sure that the top-most query node is `SeafowlDirectScan`. For example: - -``` -explain select count from (select count(*) from tpch_sf_1.lineitem); - QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- - Aggregate (cost=167.52..167.55 rows=1 width=8) - -> Append (cost=0.00..165.01 rows=1001 width=0) - -> Seq Scan on lineitem lineitem_1 (cost=0.00..0.00 rows=1 width=0) - -> SeafowlScan on "16529" lineitem_2 (cost=100.00..150.00 rows=1000 width=0) - SeafowlPlan: logical_plan - TableScan: tpch_sf_1.lineitem projection=[l_orderkey, l_partkey, l_suppkey, l_linenumber, l_quantity, l_extendedprice, l_discount, l_tax, l_returnflag, l_linestatus, l_shipdate, l_commitdate, l_receiptdate, l_shipinstruct, l_shipmode, l_comment] -(6 rows) -``` - - -In this case, the query is executed by PostgreSQL and Seafowl is only involved -when scanning the table (see `SeafowlScan` at the bottom). The fix in this case is -to explicitly name the inner `COUNT(*)` column, since Seafowl gives it an implicit -name `count(*)` whereas PostgreSQL calls it `count`: - - -``` -edb_admin=> explain select count from (select count(*) as count from tpch_sf_1.lineitem); - QUERY PLAN --------------------------------------------------------------------- - SeafowlDirectScan: logical_plan - Projection: COUNT(*) AS count - Aggregate: groupBy=[[]], aggr=[[COUNT(UInt8(1)) AS COUNT(*)]] - TableScan: tpch_sf_1.lineitem projection=[] -(4 rows) -``` - -Here, we can see the `SeafowlDirectScan` at the top, which means that Seafowl is -running the entire query. - -If you're having trouble rewording your query to make it run fully on Seafowl, -open a support ticket. - -## Load data with Lakehouse sync - -If you have a transactional database running in EDB Postgres AI Cloud Service, -then you can sync tables from this database into a Managed Storage Location. - -A more detailed guide for this is forthcoming. If you want to try it yourself, -look in the UI for "Migrations" or "Sync to Lakehouse." - -## Advanced: Bring your own data - -It's possible to point your Lakehouse node at an arbitrary S3 bucket with Delta -Tables inside of it. However, this comes with some major caveats (which will -eventually be resolved): - -### Caveats - -* The bucket must be publicly accessible. - * If you want to use a private bucket, this is technically possible, but -requires some manual action on our side and your side (to assign the correct -IAM policies). Let us know if you want to try it. We will be adding -proper support for private, external buckets in the near future. -* The tables must be stored as [Delta Tables](http://github.com/delta-io/delta/blob/master/PROTOCOL.md) within the location -* A “Delta Table” is a folder of Parquet files along with some JSON metadata. -* Each table must be prefixed with a `$schema/$table/` where `$schema` and `$table` are valid Postgres identifiers (i.e. < 64 characters) - * For example, this is a valid Delta Table that will be recognized by Beacon Analytics: - * `my_schema/my_table/{part1.parquet, part2.parquet, _delta_log}` - * These `$schema` and `$table` identifiers will be queryable in the Lakehouse node, e.g.: - * `SELECT count(*) FROM my_schema.my_table;` - * This Delta Table will NOT be recognized by Beacon Analytics (missing a schema): - * `my_table/{part1.parquet, part2.parquet, _delta_log}` - - -### Loading your own data - -* You can use the [deltalake](https://pypi.org/project/deltalake/) Python library -to create Delta Tables and write to the bucket -* You can also use the [`lakehouse-loader`](https://github.com/splitgraph/lakehouse-loader) utility -we created for this, to export data from an arbitrary Postgres instance to Lakehouse Tables -in a storage bucket. - -For example, with the `lakehouse-loader` utility: - -```bash -export PGPASSWORD="..." -export AWS_ACCESS_KEY_ID="..." -export AWS_SECRET_ACCESS_KEY="..." -# export other AWS envvars - -./lakehouse-loader postgres-to-delta postgres://test-user@localhost:5432/test-db -q "SELECT * FROM some_table" s3://my-bucket/my_schema/my_table -``` - -### Pointing to your bucket - -By default, each Lakehouse node is configured to point to a bucket with -benchmarking datasets inside. To point it to a different bucket, you can -call the `seafowl.set_bucket_location` function: - -```sql -SELECT seafowl.set_bucket_location('{"region": "ap-south-1", "bucket": "my-bucket", "public": true}'); -``` - -### Querying your own data - -In the example above, after you've called `set_bucket_location`, you will be able -to query data in `my_schema.my_table`: - -```sql -SELECT * FROM some_table; -``` - -Note that using an S3 bucket that isn't in the same region as your node -will 1) be slow because of cross-region latencies, and 2) will incur -AWS costs (between $0.01 and $0.02 / GB) for data transfer! Currently these -egress costs are not passed through to you but we do track them and reserve -the right to terminate an instance. - -### Switching back to sample data - -To switch the bucket back to the default sample bucket in the same region as your node: - -```sql -SELECT seafowl.set_bucket_location(NULL) -``` - diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference/datasets.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference/datasets.mdx new file mode 100644 index 00000000000..4bad22d7ada --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/reference/datasets.mdx @@ -0,0 +1,35 @@ +--- +title: Benchmarking datasets +description: Benchmarking datasets available for Lakehouse +--- + +When you provision a Lakehouse node, it comes pre-configured to point to a public +S3 bucket in its same region, containing sample benchmarking datasets. + +You can query tables in these datasets by referencing them with their schema +name. + +| Schema Name | Dataset | +| --------------- | ---------------------------- | +| `tpcds_sf_1` | TPC-DS, Scale Factor 1 | +| `tpcds_sf_10` | TPC-DS, Scale Factor 10 | +| `tpcds_sf_100` | TPC-DS, Scale Factor 100 | +| `tpcds_sf_1000` | TPC-DS, Scale Factor 1000 | +| `tpch_sf_1` | TPC-H, Scale Factor 1 | +| `tpch_sf_10` | TPC-H, Scale Factor 10 | +| `tpch_sf_100` | TPC-H, Scale Factor 100 | +| `tpch_sf_1000` | TPC-H, Scale Factor 1000 | +| `clickbench` | ClickBench, 100 million rows | +| `brc_1b` | Billion row challenge | + +!!!note Notes about ClickBench data: + +Data columns (`EventData`) are integers, not dates. + +You must quote ClickBench column names, because they contain uppercase letters, +but unquoted identifiers in Postgres are case-insensitive. For example: + +✅ `select "Title" from clickbench.hits;` + +🚫 `select Title from clickbench.hits;` +!!! diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference/delta_tables.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference/delta_tables.mdx new file mode 100644 index 00000000000..8e67938baca --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/reference/delta_tables.mdx @@ -0,0 +1,30 @@ +--- +title: Delta Lake Table tools +navTitle: Delta Lake Table tools +description: Tools for working with Delta Lake Tables +--- + +## Creating Delta Lake Tables + +### Using the `deltalake` Python library + +You can use the [deltalake](https://pypi.org/project/deltalake/) Python library to create Delta Tables and write to the bucket + +### Using the `lakehouse-loader` utility + +You can also use the [`lakehouse-loader`](https://github.com/splitgraph/lakehouse-loader) utility that EDB has created for this task, to export data from an arbitrary Postgres instance to Lakehouse Tables in a storage bucket. + +For example, with the `lakehouse-loader` utility: + +```bash +export PGPASSWORD="..." +export AWS_ACCESS_KEY_ID="..." +export AWS_SECRET_ACCESS_KEY="..." +# export other AWS envvars + +./lakehouse-loader postgres-to-delta postgres://test-user@localhost:5432/test-db -q "SELECT * FROM some_table" s3://my-bucket/my_schema/my_table +``` + +This will export the data from the `some_table` table in the `test-db` database to a Delta Table in the `my_schema/my_table` path in the `my-bucket` bucket. + +You can now query this table in the Lakehouse node by creating an external table that references the Delta Table in the `my_schema/my_table` path. See [External Tables](../external_tables) for the details on how to do that. diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference/directscan.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference/directscan.mdx new file mode 100644 index 00000000000..5ae5533fda5 --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/reference/directscan.mdx @@ -0,0 +1,52 @@ +--- +title: DirectScan, fallback modes, and EXPLAIN +navTitle: DirectScan +description: Lakehouse is fastest when it can "push down" your entire query to DataFusion. This explains how to check if your query is running in DirectScan mode. +--- + +Postgres Lakehouse is fastest when it can "push down" your entire query to +DataFusion, the vectorized query used for handling queries when possible. (In the +future, this will be more fine-grained as we add support for partial pushdowns.) + +Postgres Lakehouse can execute your query in two modes. First, it attempts to +run the entire query using Seafowl (a dedicated columnar database based on +DataFusion). If Seafowl can't run the entire query, for example, because it +uses PostgreSQL-specific operations like JSON, then Postgres Lakehouse will fall +back to using the PostgreSQL executor, with Seafowl streaming full table +contents to it. + +If your query is extremely slow, it's possible that's what's happening. + +You can check which mode is being used by running an `EXPLAIN` on the query and +making sure that the top-most query node is `DirectScan`. For example: + +``` +explain select count from (select count(*) from tpch_sf_1.lineitem); + QUERY PLAN +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ + Aggregate (cost=167.52..167.55 rows=1 width=8) + -> Append (cost=0.00..165.01 rows=1001 width=0) + -> CompatScan on "16529" lineitem_2 (cost=100.00..150.00 rows=1000 width=0) + SeafowlPlan: logical_plan + TableScan: tpch_sf_1.lineitem projection=[l_orderkey, l_partkey, l_suppkey, l_linenumber, l_quantity, l_extendedprice, l_discount, l_tax, l_returnflag, l_linestatus, l_shipdate, l_commitdate, l_receiptdate, l_shipinstruct, l_shipmode, l_comment] +(6 rows) +``` + + +In this case, the query is executed by PostgreSQL and Seafowl is only involved when scanning the table (see `CompatScan` at the bottom). +The fix in this case is to explicitly name the inner `COUNT(*)` column, since Seafowl gives it an implicit name `count(*)` whereas PostgreSQL calls it `count`: + +```console +edb_admin=> explain select count from (select count(*) as count from tpch_sf_1.lineitem); + QUERY PLAN +-------------------------------------------------------------------- + DirectScan: logical_plan + Projection: COUNT(*) AS count + Aggregate: groupBy=[[]], aggr=[[COUNT(UInt8(1)) AS COUNT(*)]] + TableScan: tpch_sf_1.lineitem projection=[] +(4 rows) +``` + +Here, we can see the `DirectScan` at the top, which means that Seafowl is running the entire query. + +If you're having trouble rewording your query to make it run fully on Seafowl, open a support ticket. diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference/functions.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference/functions.mdx new file mode 100644 index 00000000000..4e3c0f68c67 --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/reference/functions.mdx @@ -0,0 +1,36 @@ +--- +title: PGAA functions reference +navTitle: Functions +description: Reference for the functions provided by the PGAA extension +--- + + +## `pgaa.create_storage_location` + +### Synopsis + +Creates a new storage location that references an S3-compatible object storage location. + +### Parameters + +| Parameter | Type | Description | +| --- | --- | --- | +| `name` | `text` | The name of the storage location | +| `uri` | `text` | The URI of the S3-compatible object storage location, for example, `s3://bucket-name` or `s3://bucket-name/prefix` | +| `options` | `json` | Optional settings for the storage location | + +#### Options + +| Option | Type | Description | +| --- | --- | --- | +| `access_key_id` | `text` | The access key ID for the storage location | +| `secret_access_key` | `text` | The secret access key for the storage location | +| `session_token` | `text` | The session token for the storage location | +| `region` | `text` | The region for the storage location | +| `endpoint` | `text` | The endpoint for the storage location | +| `bucket` | `text` | The bucket for the storage location | +| `use_http` | `boolean` | Use HTTP instead of HTTPS for the storage location | +| `skip_signature` | `boolean` | Skip signature verification for the storage location | + + + diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference/index.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference/index.mdx new file mode 100644 index 00000000000..bc01edb4a9c --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/reference/index.mdx @@ -0,0 +1,25 @@ +--- +title: Reference - EDB Postgres® AI Lakehouse +navTitle: Reference +description: Things to know about EDB Postgres® AI Lakehouse +deepToC: true +navigation: +- providers_and_regions +- instances +- datasets +- queries +- deltatables +- functions +- directscan +- users +- loading_data +--- + +EDB Postgres® AI Lakehouse is an early product. Eventually, it will support deployment modes across multiple clouds and on-premises. +However, currently it's fairly limited in terms of where you can deploy it and what data you can query with it. + +To get the best experience with Lakehouse, you should follow the [Quick start](../quick_start) to query benchmarking data. +Then you can try loading your own data with Lakehouse Sync or you can bring your own data and use [external tables](../external_tables). +If you're intrigued, reach out to us and we can talk more about your use case and potential opportunities. + +This section details some of the important things you should know. diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference/instances.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference/instances.mdx new file mode 100644 index 00000000000..78801d6cb26 --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/reference/instances.mdx @@ -0,0 +1,31 @@ +--- +title: Supported AWS instances +description: Supported AWS instances for Lakehouse +--- + +When deploying a Lakehouse node, you must choose an instance type from +the `m6id` family of instances. Importantly, these instances come with NVMe +drives attached to them. + +**Instances are ephemeral.** These NVMe drives are used only for spill-out space +*while processing queries, and for caching Delta Tables on disk. +All data on the NVMe drives will be lost when the cluster is shutdown. + +**System tables are persisted.** Persistent data in system tables (users, roles, +*etc.) is stored in an attached +block storage device, and will survive a pause/resume cycle. + +**Supported instances** + +| API Name | Memory | vCPUs | Cores | Storage | +| --------------- | --------- | --------- | ----- | ------------------------------- | +| `m6id.large` | 8.0 GiB | 2 vCPUs | 1 | 118 GB NVMe SSD | +| `m6id.xlarge` | 16.0 GiB | 4 vCPUs | 2 | 237 GB NVMe SSD | +| `m6id.2xlarge` | 32.0 GiB | 8 vCPUs | 4 | 474 GB NVMe SSD | +| `m6id.4xlarge` | 64.0 GiB | 16 vCPUs | 8 | 950 GB NVMe SSD | +| `m6id.8xlarge` | 128.0 GiB | 32 vCPUs | 16 | 1900 GB NVMe SSD | +| `m6id.12xlarge` | 192.0 GiB | 48 vCPUs | 24 | 2850 GB (2 \* 1425 GB NVMe SSD) | +| `m6id.16xlarge` | 256.0 GiB | 64 vCPUs | 32 | 3800 GB (2 \* 1900 GB NVMe SSD) | +| `m6id.24xlarge` | 384.0 GiB | 96 vCPUs | 48 | 5700 GB (4 \* 1425 GB NVMe SSD) | +| `m6id.32xlarge` | 512.0 GiB | 128 vCPUs | 64 | 7600 GB (4 \* 1900 GB NVMe SSD) | + diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference/loadingdata.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference/loadingdata.mdx new file mode 100644 index 00000000000..06c67a43c64 --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/reference/loadingdata.mdx @@ -0,0 +1,26 @@ +--- +title: Loading data (sync or bring your own) +navTitle: Loading data +description: How to load data into Lakehouse +--- + +## Loading data with Lakehouse sync + +If you have a transactional database running in EDB Postgres AI Cloud Service, then you can sync tables from this database into a Managed Storage Location. See ["How to lakehouse sync"](../how_to_lakehouse_sync) for further details. + +## Bringing your own data + +It's possible to point your Lakehouse node at an arbitrary S3 bucket with Delta Tables inside of it. +However, this comes with some major caveats (which will eventually be resolved): + +### Caveats + +* The tables must be stored as [Delta Lake Tables](http://github.com/delta-io/delta/blob/master/PROTOCOL.md) within the location. +* A "Delta Lake Table" (or "Delta Table") is a folder of Parquet files along with some JSON metadata. + +### Loading data into your bucket + +You can use the `lakehouse-loader` utility to export data from an arbitrary Postgres instance to Delta Tables in a storage bucket. +See [Delta Lake Table Tools](delta_tables) for more information on how to obtain and use that utility. + +For further details, see the [External Tables](../external_tables) documentation. diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference/providers_and_regions.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference/providers_and_regions.mdx new file mode 100644 index 00000000000..e3204279b7e --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/reference/providers_and_regions.mdx @@ -0,0 +1,34 @@ +--- +title: Supported cloud providers and regions +description: Supported cloud providers and regions for Lakehouse +--- + +**AWS only**: Currently, support for all Lakehouse features (Lakehouse nodes, +Managed Storage Locations, and Lakehouse Sync) is limited to AWS. + +**EDB-hosted only**: "Bring Your Own Account" (BYOA) regions are NOT currently +supported for Lakehouse resources. Support is limited to +ONLY **EDB Postgres® AI Hosted** environments on AWS (a.k.a. "EDB-Hosted AWS regions"). + +This means you can select from one of the following regions: + +* North America + * US East 1 + * US East 2 + * US West 2 +* Europe + * EU Central 1 + * EU West 1 + * EU West 2 +* Asia + * AP South 1 +* Australia + * AP SouthEast 2 + +To be precise: + +* Lakehouse nodes can only be provisioned in EDB-hosted AWS regions +* Managed Storage Locations can only be created in EDB-hosted AWS regions +* Lakehouse Sync can only sync from source databases in EDB-hosted AWS regions + +These limitations will be removed as we continue to improve the product. Eventually, we will support BYOA, as well as Azure and GCP, for all Lakehouse use cases. diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference/queries.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference/queries.mdx new file mode 100644 index 00000000000..42e0135c529 --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/reference/queries.mdx @@ -0,0 +1,18 @@ +--- +title: Queries +description: Supported queries in Lakehouse and best practices when composing them +--- + +In general, **READ ONLY** queries are supported. You cannot write directly to object storage. +This includes all Postgres built-in functions, statements and types. +It also includes any of those provided by EPAS or PGE, depending on which distribution you choose to deploy. + +In general, you cannot insert, update, delete or otherwise modify data. +You can use `CREATE TABLE` but only to create a normal Postgres table on the node, bearing in mind that the node is ephemeral and will be destroyed when you terminate it. +You can also `CREATE TABLE... USING PGAA` to create an external table that references Delta Tables in S3-compatible object storage. +You must load data into the bucket out-of-band, either with your own ETL scripts or with Lakehouse Sync. +See [Loading Data](loadingdata) for more details. + +One exception is Postgres system tables, such as those used for storing users, roles, and grants. +These tables are stored on the local block device, which is included in backups and restores. +So you can `CREATE USER` or `CREATE ROLE` or `GRANT USAGE`, and these users/roles/grants will survive restarts and restores. diff --git a/advocacy_docs/edb-postgres-ai/analytics/reference/users.mdx b/advocacy_docs/edb-postgres-ai/analytics/reference/users.mdx new file mode 100644 index 00000000000..8ae12e6e06d --- /dev/null +++ b/advocacy_docs/edb-postgres-ai/analytics/reference/users.mdx @@ -0,0 +1,10 @@ +--- +title: User management +description: Managing users in Lakehouse +--- + +When you provision a Lakehouse node, you must provide a password. We do not +save this password. You will need it to login as the `edb_admin` user. This is +not a superuser account, but it does have the ability to create users and roles +and grants. Thus, you can either share the credentials for `edb_admin` itself, +or you can create other users and distribute those.