[ozgrakkurt]

It is a crime that postgres isn't able to allocate with 1GB huge pages by changing a config parameter in 2026

Also a crime that people are still running databases with 4kb pages.

To put it in perspective, this means you will have more than 30 million pages on a server with 128GB RAM. As an example, if there is 16bytes of metadata for memory page. The metadata itself would take more than half a gigabyte.

[dezgeg]

Even worse, the actual struct page on Linux is 64 bytes, so 4x your example

[anarazel]

> It is a crime that postgres isn't able to allocate with 1GB huge pages by changing a config parameter in 2026

It is able to? Configure huge_page_size=1GB?

Support for 2MB pages was added in 2014, for larger pages 2020.

Edit: year details.

[ozgrakkurt]

Didn't know that, thanks. Sorry for the wrong comment.

[ldargin]

Database systems lock pages when writing to them, to maintain integrity. Using 1GB pages would cause excessive blocking in many if not most transactional databases.

[jlokier]

In database engines that use page locks, the locked page size can be different from the file/mapped/allocated page sizes. If you still have excessive locking while using smaller page locks, there are other ways to reduce contention as well, such as CoW to protect concurrent reads, deferred write-merging to assist concurrent writes, and the storage equivalent of RCU.

[andrewf]

I don't think hardware page size has to match database page size. It would if Postgres was mmap'ing it. https://www.postgresql.org/docs/current/runtime-config-prese... says the database page size is 8KB by default.

[bonzini]

There is 64 bytes of metadata per memory page indeed.

[andrewstuart]

Sensible defaults would be nice.