Webinar Recap | Deep Dive into the Six Major New Features of PostgreSQL 18

• It is not suitable when there is no capacity to perform self-pressure tests to calculate various AIO-related GUC parameters required for one's own production environment;
• It is not suitable for heavy write scenarios (PG 18 AIO does not yet support writes);
• It is not suitable to use io_uring as the AIO underlying implementation on old Linux kernels.

Specifically: For Linux kernel versions < 5.1, the original PostgreSQL 18 cannot use io_methods=io_uring; for Linux kernels < 5.6, it is not recommended to use io_method=io_uring.

Since PostgreSQL itself is completely decoupled from the authorization server, resource consumption primarily depends on the authorization server.

For the authorization server, performance consumption involves tasks like token generation, handling network requests, and maintenance work such as log collection and archiving, which consume CPU and memory resources. The storage of tokens and the MAP relationship between database users and tokens will consume server storage resources. Overall, CPU and memory consumption depend on the authorization frequency (the login frequency of PostgreSQL users), while storage consumption depends on the number of PostgreSQL users.

From a network overhead perspective, PostgreSQL 18 needs to make multiple HTTP requests to the authorization server for initial token acquisition. High network latency will affect login time. Additionally, users need to send HTTP requests to the authorization server for verification, so the network latency between the user and the authorization server must also be considered. During token verification, if an external validator and the PostgreSQL server are on the same machine, there is no network communication; however, if online token verification is used, the latency between the PostgreSQL server and the authorization server must be taken into account.

To optimize performance, the authorization server should be placed in the same local network as PostgreSQL as much as possible, and local verification can be considered for external validators to reduce network overhead.

In PostgreSQL 18, tables with virtual columns can actually undergo logical replication. Because the value of a virtual column depends on other columns, as long as those other columns are replicated, the virtual column value can be calculated during a query. Logical replication simply cannot specify a virtual column individually (since virtual columns do not store values), but it can specify stored columns.