For businesses running 1C:Enterprise, database stability and speed aren't nice-to-haves—they're make-or-break. At Postgres Professional, we're constantly working on the DBMS core, eliminating architectural bottlenecks that show up under the heavy loads typical of 1C deployments.
We've just released Postgres Pro Enterprise 17.6 with a fresh batch of improvements specifically for 1C users.
Documentation for configuring Postgres Pro with 1C
Let's start with something our partners and clients have been asking about for ages. Until now, admins had to piece together the right DBMS configuration from scattered sources across the internet. We've finally published an official documentation section Configuring Postgres Pro for 1C solutions. It's a consolidated set of best practices that answers most questions about performance tuning and proper cluster operation.
Fewer messages between server processes
Anyone working with high-load databases knows the pain of excessive catalog cache invalidation messages. We'd already optimized this mechanism for tables, but in this release, we've gone further (building on what we did in version 14.7). Now we suppress these messages when creating or dropping indexes on temporary tables, and when gathering statistics on them.
Since temporary objects are only visible within the current session, there's no point broadcasting notifications to other processes. On top of that, we've replaced spinlocks in the shared message queue with more efficient synchronization primitives. This removes a bottleneck when processes are competing heavily for resources.
No more lock overhead on temporary table indexes
Even brief locks when working with temporary tables can eat up noticeable CPU cycles. We've introduced the skip_temp_rel_lock parameter, which skips lock acquisition not just for temporary relations themselves, but for their indexes too. This is a logical extension of functionality we added in version 17.4, and it delivers real performance gains on frequent DDL operations.
Smarter cleanup of temporary tables
Previously, TRUNCATE operations weren't as efficient as they could be: the system had to scan the entire local buffer pool separately for each layer of a relation (the table itself, its TOAST table, and indexes).
We've reworked this algorithm. Now, information about buffers to be deleted is collected upfront, and the pool is scanned just once for all layers at the same time. This speeds up non-transactional truncation of temporary tables and cuts down on overhead.
Faster search in 1C dynamic lists
1C makes heavy use of substring searches. For LIKE operators on mvarchar fields (used for MS SQL compatibility), the planner could misjudge selectivity and pick suboptimal plans. We've fixed this: cost estimation now works correctly, allowing the optimizer to choose index access over sequential scans more often.
Optimizing queries with ANTI JOIN
Complex queries with NOT EXISTS or NOT IN constructs, which get translated to ANTI JOIN, could run slowly due to identical scans for the same parameters.
We've added memoization support for parameterized ANTI JOIN nodes in the optimizer. This means computation results for specific parameters get cached and reused, eliminating redundant data processing cycles.
Better locking during query planning
When executing queries involving many relations, there was high contention for locks on the pg_attribute and pg_statistic system tables. We've optimized this mechanism, reducing the number of lock requests needed when information isn't in cache. This makes the system run more smoothly when lots of new sessions (with empty caches) connect and immediately try to run large queries on tables with wide indexes.
Optimized VACUUM ANALYZE on catalog tables
Previously, analyzing system catalog tables would invalidate the pg_internal.init file—a crucial cache of system catalog information. Rebuilding it consumed resources and could slow down user connections.
We've changed the algorithm: pg_internal.init no longer gets invalidated when analyzing the catalog, even if statistics are updated frequently. This ensures new sessions connect quickly without delays, regardless of background maintenance processes.
Wrapping up
These changes are the result of deep analysis of how Postgres Pro performs under loads typical of large enterprise systems. We're continuing to refine the product, focusing on real-world performance and scalability challenges. You can learn more about these and other features that optimize 1C:Enterprise operation on the Postgres Pro Enterprise for 1C page.