Postgres does not use O_DIRECT for data (contrasting to the write ahead log / journal, where it can in some configurations), neither when reading, nor when writing. So data will definitely pass through the kernel page cache.
By default we force the kernel's hand about when to write data back to disk from the page cache for a lot of the writes (from the checkpointing process and the background writer, but not by backends themselves - it can be enabled for backends too, and is often beneficial), as disk performance otherwise is quite unpredictable (with long stalls when the OS decides to trigger writeback).
For some workloads, in particular large and high read/write volume databases, it'd be very beneficial to support O_DIRECT for data too, but there's some work on postgres' IO subsystem needed to make that doable without performance regressions in a lot of scenarios.
Even once we add it, it's unlikely to become the default, at least for reads, as using O_DIRECT would require somewhat accurate tuning of postgres. Even for databases without high throughput. Whereas also utilizing the OS page cache doesn't require accurate sizing of shared_buffers etc, and adapts to changing workloads and global resource availability.
Comments
Postgres does not use O_DIRECT for data (contrasting to the write ahead log / journal, where it can in some configurations), neither when reading, nor when writing. So data will definitely pass through the kernel page cache.
By default we force the kernel's hand about when to write data back to disk from the page cache for a lot of the writes (from the checkpointing process and the background writer, but not by backends themselves - it can be enabled for backends too, and is often beneficial), as disk performance otherwise is quite unpredictable (with long stalls when the OS decides to trigger writeback).
For some workloads, in particular large and high read/write volume databases, it'd be very beneficial to support O_DIRECT for data too, but there's some work on postgres' IO subsystem needed to make that doable without performance regressions in a lot of scenarios.
Even once we add it, it's unlikely to become the default, at least for reads, as using O_DIRECT would require somewhat accurate tuning of postgres. Even for databases without high throughput. Whereas also utilizing the OS page cache doesn't require accurate sizing of shared_buffers etc, and adapts to changing workloads and global resource availability.