Database Technology

Andrei Lepikhov investigates why PostgreSQL's numeric type remains inefficient for aggregations despite 25 years of optimization. The analysis compares Postgres against DuckDB, an OLAP engine that prioritizes speed over strict exactness. While AI-assisted source code review highlights structural limitations in Postgres, the comparison underscores the trade-offs between precision and performance.

• PostgreSQL numeric operations lag in aggregation efficiency compared to specialized OLAP engines.
• DuckDB achieves speed by relaxing strict exactness requirements for numerical calculations.
• Structural limitations in Postgres may prevent further optimization of the numeric type.
• AI tools are now being used to automate complex source code analysis for DB internals.

Igor Suhorukov ported Apache Cloudberry to PostgreSQL 19 as extensions, finding it trails columnar engines on ClickBench by an order of magnitude. The bottleneck is PostgreSQL's row-based executor, where values pass through fmgr individually, forcing segments to repeat the same inefficient loop. Open-source Cloudberry lacks a true vectorized executor, retaining only stubs like a false vectorization flag and an unimplemented WindowHashAgg.

• PostgreSQL 19's row executor creates a performance ceiling for columnar workloads compared to dedicated engines.
• Cloudberry's open-source port lacks a vectorized executor, relying on stubs from its closed-source predecessor.
• MPP scaling is negated by per-row processing overhead and fmgr calls in the current execution model.
• Vectorization is identified as the critical next step to close the performance gap with columnar databases.

This article traces the lifecycle of a single page from disk storage through the shared buffer pool and back, explicitly identifying the underlying file in the data directory. It explains the naming scheme, size limits, and companion files associated with each relation, using PostgreSQL 18.6 as the reference version. The author demonstrates how to locate and verify these files using basic shell tools like ls and od, confirming that the bytes in the buffer match those on disk.

• Every page in the buffer pool originates from a specific file under the base/ directory.
• PostgreSQL 18.6 uses data checksums by default, enhancing data integrity verification.
• The pageinspect extension is required to inspect page contents programmatically.
• Basic shell tools (ls, od) are sufficient to map and verify on-disk file structures.
• Understanding file naming and size limits aids in low-level storage troubleshooting.

Kaarel Moppel has published an OLTP performance check on Postgres 19 Beta 3.5, marking the annual release cycle. The post acknowledges the usual release-day anxieties and obstacles surrounding the launch, though it does not delve into the technical specifics of the benchmark results or the causes of the delays.

• Postgres 19 Beta 3.5 is available for early performance testing.
• The release cycle is facing typical pre-launch obstacles and anxiety.
• Author focuses on the release timing rather than detailed benchmark data.
• Practitioners should monitor for the final release stability before upgrading.

Valkey, the Redis fork launched over two years ago, is evolving with support from twelve maintainers and nine committee members. Recent updates focus on enhanced throughput and improved cluster functionality, while future plans include synchronous replication and tiered storage. The project is also prioritizing security and release efficiency through increased automation.

• Valkey now has 12 maintainers and 9 committee members across multiple companies.
• Future features include synchronous replication and tiered storage capabilities.
• Recent improvements target higher throughput and more robust cluster functionality.
• Release efficiency and security are being bolstered via new automation processes.