SQLHUB Telegram 2035
🗄 MySQL vs Postgres: как кэшируют страницы данных

Подходы разные:
- MySQL (InnoDB) стремится всё держать под своим контролем
- Postgres больше доверяет операционной системе

MySQL / InnoDB
- Своя память под кэш: innodb_buffer_pool_size обычно = 70%+ RAM на выделенном сервере
- Обход кэша ОС: с innodb_flush_method='O_DIRECT' InnoDB работает напрямую с диском
- Двухсекционный LRU: страницы сначала в old, только потом (через innodb_old_blocks_time`) в `young. Это спасает от «выметания» кэша при больших сканах

Postgres
- Внутренний кэш + page cache ОС: shared_buffers обычно около 30% RAM, остальное оставляют ОС
- Clock-sweep: у страницы счётчик обращений, уменьшается при «прокрутке часов». Когда падает до нуля — страница освобождается

Практические выводы
- Bulk-операции: InnoDB устойчивее к «пробиванию» кэша, в Postgres часть нагрузки идёт в кэш файловой системы
- Тюнинг памяти: в MySQL раздувают buffer pool, в Postgres shared_buffers умеренный, а остальное доверяют ОС

Что стоит проверить в бенчмарках Postgres
- Размер shared_buffers: 4% / 10% / 30% / 50% RAM
- Сценарии: OLTP, последовательные сканы, смешанные нагрузки
- Рабочий набор: меньше / равен / больше доступной RAM
- Метрики: TPS/QPS, p95/p99 латентность, hit ratio, про

https://github.com/postgres/postgres/blob/master/src/backend/storage/buffer/README
5👍5🔥3



tgoop.com/sqlhub/2035
Create:
Last Update:

🗄 MySQL vs Postgres: как кэшируют страницы данных

Подходы разные:
- MySQL (InnoDB) стремится всё держать под своим контролем
- Postgres больше доверяет операционной системе

MySQL / InnoDB
- Своя память под кэш: innodb_buffer_pool_size обычно = 70%+ RAM на выделенном сервере
- Обход кэша ОС: с innodb_flush_method='O_DIRECT' InnoDB работает напрямую с диском
- Двухсекционный LRU: страницы сначала в old, только потом (через innodb_old_blocks_time`) в `young. Это спасает от «выметания» кэша при больших сканах

Postgres
- Внутренний кэш + page cache ОС: shared_buffers обычно около 30% RAM, остальное оставляют ОС
- Clock-sweep: у страницы счётчик обращений, уменьшается при «прокрутке часов». Когда падает до нуля — страница освобождается

Практические выводы
- Bulk-операции: InnoDB устойчивее к «пробиванию» кэша, в Postgres часть нагрузки идёт в кэш файловой системы
- Тюнинг памяти: в MySQL раздувают buffer pool, в Postgres shared_buffers умеренный, а остальное доверяют ОС

Что стоит проверить в бенчмарках Postgres
- Размер shared_buffers: 4% / 10% / 30% / 50% RAM
- Сценарии: OLTP, последовательные сканы, смешанные нагрузки
- Рабочий набор: меньше / равен / больше доступной RAM
- Метрики: TPS/QPS, p95/p99 латентность, hit ratio, про

https://github.com/postgres/postgres/blob/master/src/backend/storage/buffer/README

BY Data Science. SQL hub




Share with your friend now:
tgoop.com/sqlhub/2035

View MORE
Open in Telegram


Telegram News

Date: |

Joined by Telegram's representative in Brazil, Alan Campos, Perekopsky noted the platform was unable to cater to some of the TSE requests due to the company's operational setup. But Perekopsky added that these requests could be studied for future implementation. Polls During the meeting with TSE Minister Edson Fachin, Perekopsky also mentioned the TSE channel on the platform as one of the firm's key success stories. Launched as part of the company's commitments to tackle the spread of fake news in Brazil, the verified channel has attracted more than 184,000 members in less than a month. Commenting about the court's concerns about the spread of false information related to the elections, Minister Fachin noted Brazil is "facing circumstances that could put Brazil's democracy at risk." During the meeting, the information technology secretary at the TSE, Julio Valente, put forward a list of requests the court believes will disinformation. The public channel had more than 109,000 subscribers, Judge Hui said. Ng had the power to remove or amend the messages in the channel, but he “allowed them to exist.”
from us


Telegram Data Science. SQL hub
FROM American