We work hard on developing new features for Postgres Pro DBMS. Being a part of international PostgreSQL developers community, we consider contributing to PostgreSQL as an important part of out work.
The main directions of our development effort are described below.
Traditional for PostgreSQL table partitioning through inheritance has many disadvantages, including the performance degradation with large number of partitions. We develop new partitioning subsystem working at the query planning and execution levels.
We achieved a significant progress in PostgreSQL extendability: FDWs, custom access methods, generic WAL. And we’re not so far from having pluggable storage engines. Concept of API was presented at PGCon 2016.
We work on several backup problems: block-level incremental backup, backup validation, partial backup/restore.
Current approach for execution is essentially a kind plan tree interpretation. JIT-compilation of queries means compilation of plan tree into binary. Such compilation could get rid of multiple levels of indirection therefore accelerating queries.
Multi-master cluster with sharding which provides read/write scalability as well as high availability is obviously one of most wanted DBMS features. Experience shows that we should move in step-by-step manner in order to have it in core one day. Postgres Professional company joins community efforts in this direction.
Business-critical applications require continuous monitoring and adjustment of query plans. The problem hardens due the fact that actual resources consumption by query execution could differ significantly with slight changes of the query plan cost. Thus, there is a permanent risk of bad plan selection and overall system performance degradation after collecting new statistics. DBAs want to protect themselves from this risk by freezing plans of particular most critical queries.
Working with large number of simultaneous connections almost inevitably leads to usage of connection pools. Unfortunately, present pooling solutions are very limited in access to all PostgreSQL features.
We develop new algorithms to make the query plans better.
PGLZ compression of individual values is used now in PostgreSQL. That’s good, but sometimes it’s possible to achieve significant compression only when compressing multiple values together. This is why we’re considering page-level data compression.
Temporary tables are often being used. Their performance could be increased if they are removed from system catalog. Also it is attractive to allow using temporary tables on read-only standbys.