3. What are the differences between Tantor BE 17 and PostgreSQL 17#
3. What are the differences between Tantor BE 17 and PostgreSQL 17 #
3.1. Helpful links #
3.2. Core improvements #
Optimized
pglzdata compression algorithm (~1.4 times).Optimized replication recovery process (
fadviseon standby).Expanded use of SIMD instructions. Enhancements planned for PostgreSQL 18 are already available in Tantor BE 17.
Optimization for linear search for ARM64 architecture processors.
When sending the WAL to the standby server, a checksum of the data blocks is verified.
Increased informative value of diagnostic information:
Diagnostics of internal DBMS errors (
backtrace_on_internal_errorparameter).The informativeness of the DBMS server logs — the start messages contain additional diagnostic information.
The pg_controldata server application contains additional meta information about the edition and assembly to simplify the diagnosis of possible problems.
The maximum size of data in table cells supported by the pg_dump module is 2 GB.
Query sampling support in pg_stat_statements: optional sampling reduces the monitoring overhead under high load, ensuring that query statistics are collected with minimal impact on overall system performance.
Increased number of partitions in the shared buffers.
3.3. Additional Supplied Utilities #
pg_diag_setup — automates the configuration of Tantor BE performance diagnostics extensions such as
pg_store_plans,pg_stat_statements,pg_stat_kcache,auto_explain,pg_buffercache, and others. This simplifies the integration of database monitoring systems.pg_sec_check — audits the security of Tantor BE database configurations. It automates the inspection of various security aspects: from server settings to database-specific parameters, and provides detailed reports on identified issues along with actionable recommendations for remediation.
pgcompacttable — reduces the size of bloated tables and indexes without using heavy locks. It is developed to reorganize data in tables and rebuild indexes in order to reclaim disk space without impacting database performance.
pgcopydb — automates running pg_dump | pg_restore between two running Postgres servers. To make a copy of a database to another server as quickly as possible, one would like to use the parallel options of pg_dump and still be able to stream the data to as many pg_restore jobs.
3.4. Additionally supplied modules (extensions) #
page_repair - designed to repair separate corrupted pages using backup data from the replication server. It allows saving reparation time as it does not require reparation of all data, but separate pages.
pg_background - allows executing commands in the background mode such as VACUUM and CREATE INDEX CONCURRENTLY from SQL along with launching autonomous transactions.
pg_cron - represents a cron-based job scheduler working within the database as an extension. It uses the same syntax as regular cron, but it allows scheduling Tantor DBMS commands directly from the database.
pg_repack - removes bloat from tables and indexes, and optionally restores the physical order of clustered indexes. Unlike CLUSTER and VACUUM FULL it works online, without holding an exclusive lock on the processed tables during processing.
pg_stat_advisor - allows to analyze query performance and create additional statistics to improve query plan.
pg_stat_kcache - gathers statistics about real reads and writes done by the filesystem layer.
pg_store_plans - provides the means to keep track of the execution plan statistics for all SQL statements executed by the Tantor server.
pg_uuidv7 - provides support for working with the UUIDv7 data type.
pg_wait_sampling - provides information about current waiting event for a certain process. However, to collect a descriptive statistics of server behaviour a user must repeatedly collect the current waiting event. This module represents an extension for collecting sample statistics of waiting events that prevent needless sampling of the current event waiting.
pgaudit - provides detailed session and/or object audit logging via the standard Tantor DBMS logging facility. The goal of the pgAudit is to provide Tantor DBMS users with capability to produce audit logs often required to comply with government, financial, or ISO certifications.
pgauditlogtofile - is an addon to pgAudit than will redirect audit log lines to an independent file, instead of using PostgreSQL server logger. This will allow us to have an audit file that we can easily rotate without polluting server logs with those messages. Audit logs in heavily used systems can grow very fast. This extension allows to automatically rotate the files based in a number of minutes.
pgl_ddl_deploy - is an extension for sending DDL commands to a replica server during logical replication.
wal2json - is an output plugin for logical decoding. It means that the plugin have access to tuples produced by INSERT and UPDATE. Also, UPDATE/DELETE old row versions can be accessed depending on the configured replica identity. Changes can be consumed using the streaming protocol (logical replication slots) or by a special SQL API.
3.5. Additionally supplied programs #
Tantor Platform: full-featured modular platform for administration and monitoring of Tantor RDMS and most PostgreSQL based clusters. The platform simplifies daily RDBMS operation with significant impact on the RDBMS management simplicity. The software functionality includes: smart and simple user interface, cluster automatic adaptive tuning, system overview, alerts and monitoring, automatic health checks and schema audit, maintenance tasks resolution through the GUI, advanced query profiling, and administering multiple servers in one place;
pg_anon: is a standalone Python program to work with Tantor RDMS or PostgreSQL based DB to perform data masking and anonymization during data migration between production and test environments;
wal-g: is a tool for making encrypted, compressed Tantor BE backups (full and incremental) and push/fetch them to/from storage without saving it on your filesystem;
pg_configurator: is a PostgreSQL configuration tool;
pg_cluster: is an ansible playbook for PostgreSQL high availability cluster on Patroni.
3.6. Programmatic Interfaces for Various Languages #
Tantor BE provides a wide range of drivers and libraries to interact with the database from various programming languages and environments. The following sections outline the main interfaces and their respective tools.
3.6.1. C/C++ #
libpq: The primary C library for Tantor BE client programs. It allows sending queries, receiving results, and managing connections.
libpqxx: A C++ wrapper over libpq, offering a more modern and user-friendly interface for C++ developers.
3.6.2. Java/JDBC #
PostgreSQL JDBC Driver: The official JDBC driver that enables Java applications to interact with Tantor BE databases using the standard JDBC API.
3.6.3. .NET #
Npgsql: An open-source .NET Data Provider for PostgreSQL. It allows .NET applications to use ADO.NET to connect to Tantor BE, run queries, and retrieve data.
3.6.4. ODBC #
psqlODBC: The official PostgreSQL ODBC driver providing connectivity for applications and tools using ODBC interfaces.
3.6.5. Perl #
DBD::Pg: A Perl DBI-compliant module for Tantor BE. It integrates seamlessly with the Perl DBI framework for database interactions.
3.6.6. Python #
psycopg2/psycopg: Widely used Python adapters implementing the Python DB-API specification. They provide a robust and efficient way to execute queries, handle transactions, and manage connections.
pg8000: A pure-Python alternative adapter that also supports the DB-API standard.
3.6.7. Ruby #
pg gem: The official Ruby driver for PostgreSQL, providing a native interface to execute queries and process results.
3.6.8. Tcl #
pgtcl/pgtcl-ng: Tcl extensions enabling connections to Tantor BE, execution of queries, and management of query results within Tcl scripts.
3.7. Release Notes #
The first release of Tantor BE is 17.5.0.
Significant changes can be found on the related page.
All other changes see in Release Notes.