PG-Strom v2.2 Release
PG-Strom Development Team (1-May-2019)
Overview
Major enhancement in PG-Strom v2.2 includes:
- Table partitioning support
- Columnar store support with Arrow_Fdw
- Pre-built GPU binary support
- Enables to implement GPU functions that returns variable length data
- GpuSort support on GPU memory store (Gstore_Fdw)
- NVME-oF support (Experimental)
Prerequisites
- PostgreSQL v9.6, v10, v11
- CUDA Toolkit 10.1
- Linux distributions supported by CUDA Toolkit
- Intel x86 64bit architecture (x86_64)
- NVIDIA GPU CC 6.0 or later (Pascal or Volta)
New Features
- Table partitioning support
- If multi-GPUs configuration, an optimal GPU shall be chosen according to the physical distance between GPU and child tables that construct a partition. If PG-Strom cannot identify the distance from PCIe-bus topology, like NVME-oF configuration, DBA can configure the relation of GPU and NVME-SSD using
pg_strom.nvme_distance_map
. - When we join a partitioned table with non-partition tables, this version can produce a query execution plan that preliminary joins the non-partitioned table with partition child tables for each, and gather the results from child tables. This feature is proposed to PostgreSQL v13 core, as Asymmetric Partition-wise JOIN.
- If multi-GPUs configuration, an optimal GPU shall be chosen according to the physical distance between GPU and child tables that construct a partition. If PG-Strom cannot identify the distance from PCIe-bus topology, like NVME-oF configuration, DBA can configure the relation of GPU and NVME-SSD using
- Columnar store support with Arrow_Fdw
- It supports to read external Apache Arrow files using foreign table.
- It also supports SSD-to-GPU Direct SQL on Apache Arrow files.
- Pre-built GPU binary support
- When GPU binary code is generated from SQL, the older version wrote out eitire CUDA C source code, including static portions like libraries, then NVRTC(NVIDIA Run-Time Compiker) built them on the fly. However, a part of complicated function consumed much longer compilation time.
- v2.2 preliminary builds static functions preliminary, and only dynamic portion from SQL are built dynamically. It reduces the time for GPU binary generation.
- JSONB data type support
- This version allows to reference elements of JSONB object, and to utilize them as
numeric
ortest
.
- This version allows to reference elements of JSONB object, and to utilize them as
- Enables to implement GPU functions that returns variable length data
- This version allows to implement SQL functions that returns variable-length data, like
textcat
, on GPU devices.
- This version allows to implement SQL functions that returns variable-length data, like
- GpuSort support on GPU memory store (Gstore_Fdw)
- This version allows to read data from GPU memory store for SQL workloads execution, not only PL/CUDA.
- Addition of regression test
- Several simple regression tests are added.
- NVME-oF support (Experimental)
- It supports SSD-to-GPU Direct SQL from remote SSD disks which are mounted using NVME-over-Fabric. Please note that it is an experimental feature, and it needs to replace the
nvme_rdma
kernel module on Red Hat Enterprise Linux 7.x / CentOS 7.x.
- It supports SSD-to-GPU Direct SQL from remote SSD disks which are mounted using NVME-over-Fabric. Please note that it is an experimental feature, and it needs to replace the
Features to be deprecated
-
PostgreSQL v9.6 support
- CustomScan API in PostgreSQL v9.6 lacks a few APIs to handle dynamic shared memory (DSM), so it is unable to collect run-time statistics.
- It also changes the way to keep expression objects internally, therefore, we had to put
#if ... #endif
blocks at no little points. It has damaged to code maintainability. - Due to the problems, this is the last version to support PostgreSQL v9.6. If you applied PG-Strom on PostgreSQL v9.6, let us recommend to move PostgreSQL v11 as soon as possible.
-
The
pgstrom
format of Gstore_Fdw foreign table- The internal data format on GPU memory store (Gstore_Fdw) is originally designed for data source of PL/CUDA procedures. It is our own format, and used PostgreSQL's data representations as is, like variable-length data, numeric, and so on.
- After that, NVIDIA released RAPIDS(cuDF), based on Apache Arrow, for data exchange on GPU, then its adoption becomes wider on machine-learning application and Python software stack.
- PG-Strom will switch its internal data format of Gstore_Fdw, to improve interoperability with these machine-learning software, then existing data format shall be deprecated.
Dropped Features
- In-memory columnar cache
- As results of use-case analysis, we concluded Arrow_Fdw can replace this feature in most cases. Due to feature duplication, we dropped the in-memory columnar cache.