Truncate queries on PostgreSQL do not need to fallback to delete queries

Problem/Motivation

Truncate::__toString() in core/lib/Drupal/Core/Database/Query/Truncate.php emits DELETE FROM instead of TRUNCATE when a transaction is active. On MySQL, TRUNCATE is a DDL statement and causes an implicit commit, so the fallback is needed there. On PostgreSQL, TRUNCATE is fully transactional and can be rolled back. The pgsql driver inherits the fallback anyway.

DELETE FROM is slow on large tables. Each deleted row also becomes a dead tuple that autovacuum must clean up. Frequent cache table clears create this vacuum load on PostgreSQL sites.

Proposed resolution

Override __toString() in the pgsql driver's Truncate class to always emit TRUNCATE, also inside transactions.

Caveats: TRUNCATE takes an ACCESS EXCLUSIVE lock on the table, held until the transaction ends. It is not MVCC-safe for concurrent transactions using a snapshot taken before the truncation. The core docblock already describes the lock.

Steps to reproduce

On PostgreSQL, run a truncate query inside a transaction and log the queries. A DELETE FROM statement runs.

Remaining tasks

Review.

API changes

None.

Data model changes

None.

For the committer

The changes to the .gitlab-ci.yml file need to be removed before merging!