Что нового в PostgreSQL 9.4 c точки зрения производительности

Илья Космодемьянскийik@postgresql-consulting.com

ПланУлучшения производительности

• Materialized views• Huge pages• WAL• Небольшие но приятные мелочи• Мониторинг производительности• Задел на будущее

Materialized views

• View, которая не обновляется при обращении, а хранит данные локально

• Очень ценно для OLAP и денормализации• Задача обновления данных в Mat. View - сложная• До 9.3 в PostgreSQL не было встроенной реализации• Most desired feature в TODO• Materialized views в 9.3 это PoC

Materialized views

• View, которая не обновляется при обращении, а хранит данные локально• Очень ценно для OLAP и денормализации

• Задача обновления данных в Mat. View - сложная• До 9.3 в PostgreSQL не было встроенной реализации• Most desired feature в TODO• Materialized views в 9.3 это PoC

Materialized views

• View, которая не обновляется при обращении, а хранит данные локально• Очень ценно для OLAP и денормализации• Задача обновления данных в Mat. View - сложная

• До 9.3 в PostgreSQL не было встроенной реализации• Most desired feature в TODO• Materialized views в 9.3 это PoC

Materialized views

• View, которая не обновляется при обращении, а хранит данные локально• Очень ценно для OLAP и денормализации• Задача обновления данных в Mat. View - сложная• До 9.3 в PostgreSQL не было встроенной реализации

• Most desired feature в TODO• Materialized views в 9.3 это PoC

Materialized views

• View, которая не обновляется при обращении, а хранит данные локально• Очень ценно для OLAP и денормализации• Задача обновления данных в Mat. View - сложная• До 9.3 в PostgreSQL не было встроенной реализации• Most desired feature в TODO

• Materialized views в 9.3 это PoC

Materialized views

• View, которая не обновляется при обращении, а хранит данные локально• Очень ценно для OLAP и денормализации• Задача обновления данных в Mat. View - сложная• До 9.3 в PostgreSQL не было встроенной реализации• Most desired feature в TODO• Materialized views в 9.3 это PoC

Materialized views в 9.4

• REFRESH MATERIALIZED VIEW CONCURRENTLY

• Не требуется эксклюзивная блокировка• То есть уже можно пользоваться• В силу особенностей реализации требуется Primary Key/ Unique Index

Materialized views в 9.4

• REFRESH MATERIALIZED VIEW CONCURRENTLY• Не требуется эксклюзивная блокировка

• То есть уже можно пользоваться• В силу особенностей реализации требуется Primary Key/ Unique Index

Materialized views в 9.4

• REFRESH MATERIALIZED VIEW CONCURRENTLY• Не требуется эксклюзивная блокировка• То есть уже можно пользоваться

• В силу особенностей реализации требуется Primary Key/ Unique Index

Materialized views в 9.4

• REFRESH MATERIALIZED VIEW CONCURRENTLY• Не требуется эксклюзивная блокировка• То есть уже можно пользоваться• В силу особенностей реализации требуется Primary Key/ Unique Index

Huge pages - что такое и зачем

• Сервера с большим количеством памяти (128-256Gb) теперь стоят разумныхденег

• Держать базу в памяти хорошо (любую хорошо, PostgreSQL совсем хорошо)• По умолчанию память выделяется по 4kB - так быстрее• ОС транслирует виртуальные адреса в физические, результат кэшируется вTranslation Lookaside Buffer (TLB)

• 1Gb4kB = 262144 и 64-битная адресация - на больших объемах памяти оверхэд инизкая эффективность TLB

• Выделяем память большими (например 2Mb) порциями

Huge pages - что такое и зачем

• Сервера с большим количеством памяти (128-256Gb) теперь стоят разумныхденег

• Держать базу в памяти хорошо (любую хорошо, PostgreSQL совсем хорошо)

• По умолчанию память выделяется по 4kB - так быстрее• ОС транслирует виртуальные адреса в физические, результат кэшируется вTranslation Lookaside Buffer (TLB)

• 1Gb4kB = 262144 и 64-битная адресация - на больших объемах памяти оверхэд инизкая эффективность TLB

• Выделяем память большими (например 2Mb) порциями

Huge pages - что такое и зачем

• Сервера с большим количеством памяти (128-256Gb) теперь стоят разумныхденег

• Держать базу в памяти хорошо (любую хорошо, PostgreSQL совсем хорошо)• По умолчанию память выделяется по 4kB - так быстрее

• ОС транслирует виртуальные адреса в физические, результат кэшируется вTranslation Lookaside Buffer (TLB)

• 1Gb4kB = 262144 и 64-битная адресация - на больших объемах памяти оверхэд инизкая эффективность TLB

• Выделяем память большими (например 2Mb) порциями

Huge pages - что такое и зачем

• Сервера с большим количеством памяти (128-256Gb) теперь стоят разумныхденег

• Держать базу в памяти хорошо (любую хорошо, PostgreSQL совсем хорошо)• По умолчанию память выделяется по 4kB - так быстрее• ОС транслирует виртуальные адреса в физические, результат кэшируется вTranslation Lookaside Buffer (TLB)

• 1Gb4kB = 262144 и 64-битная адресация - на больших объемах памяти оверхэд инизкая эффективность TLB

• Выделяем память большими (например 2Mb) порциями

Huge pages - что такое и зачем

• Сервера с большим количеством памяти (128-256Gb) теперь стоят разумныхденег

• Держать базу в памяти хорошо (любую хорошо, PostgreSQL совсем хорошо)• По умолчанию память выделяется по 4kB - так быстрее• ОС транслирует виртуальные адреса в физические, результат кэшируется вTranslation Lookaside Buffer (TLB)

• 1Gb4kB = 262144 и 64-битная адресация - на больших объемах памяти оверхэд инизкая эффективность TLB

• Выделяем память большими (например 2Mb) порциями

Huge pages - что такое и зачем

• Сервера с большим количеством памяти (128-256Gb) теперь стоят разумныхденег

• Держать базу в памяти хорошо (любую хорошо, PostgreSQL совсем хорошо)• По умолчанию память выделяется по 4kB - так быстрее• ОС транслирует виртуальные адреса в физические, результат кэшируется вTranslation Lookaside Buffer (TLB)

• 1Gb4kB = 262144 и 64-битная адресация - на больших объемах памяти оверхэд инизкая эффективность TLB

• Выделяем память большими (например 2Mb) порциями

Huge pages и PostgreSQL

• vm.nr_hugepages = 3170 (sysctl, ядро должно поддерживать)

• До 9.2 включительно - через библиотеку hugetlb• 9.3 улучшена работа с shared memory c помощью mmap - huge pages неработают

• huge_pages = try |on|off (postgresql.conf)• try - дефолт, не получилось, не используем• Сейчас работат только на linux, try на FreeBSD - OK

Huge pages и PostgreSQL

• vm.nr_hugepages = 3170 (sysctl, ядро должно поддерживать)• До 9.2 включительно - через библиотеку hugetlb

• 9.3 улучшена работа с shared memory c помощью mmap - huge pages неработают

• huge_pages = try |on|off (postgresql.conf)• try - дефолт, не получилось, не используем• Сейчас работат только на linux, try на FreeBSD - OK

Huge pages и PostgreSQL

• vm.nr_hugepages = 3170 (sysctl, ядро должно поддерживать)• До 9.2 включительно - через библиотеку hugetlb• 9.3 улучшена работа с shared memory c помощью mmap - huge pages неработают

• huge_pages = try |on|off (postgresql.conf)• try - дефолт, не получилось, не используем• Сейчас работат только на linux, try на FreeBSD - OK

Huge pages и PostgreSQL

• vm.nr_hugepages = 3170 (sysctl, ядро должно поддерживать)• До 9.2 включительно - через библиотеку hugetlb• 9.3 улучшена работа с shared memory c помощью mmap - huge pages неработают

• huge_pages = try |on|off (postgresql.conf)

• try - дефолт, не получилось, не используем• Сейчас работат только на linux, try на FreeBSD - OK

Huge pages и PostgreSQL

• vm.nr_hugepages = 3170 (sysctl, ядро должно поддерживать)• До 9.2 включительно - через библиотеку hugetlb• 9.3 улучшена работа с shared memory c помощью mmap - huge pages неработают

• huge_pages = try |on|off (postgresql.conf)• try - дефолт, не получилось, не используем

• Сейчас работат только на linux, try на FreeBSD - OK

Huge pages и PostgreSQL

• vm.nr_hugepages = 3170 (sysctl, ядро должно поддерживать)• До 9.2 включительно - через библиотеку hugetlb• 9.3 улучшена работа с shared memory c помощью mmap - huge pages неработают

• huge_pages = try |on|off (postgresql.conf)• try - дефолт, не получилось, не используем• Сейчас работат только на linux, try на FreeBSD - OK

Оптимизация записи в WAL

• Более одного бэкенда может писать в буферы WAL

• При апдейте в WAL может записываться только измененное поле, а не всястрока (если tuple пишется в ту же страницу)

Оптимизация записи в WAL

• Более одного бэкенда может писать в буферы WAL• При апдейте в WAL может записываться только измененное поле, а не всястрока (если tuple пишется в ту же страницу)

Небольшие но приятные мелочи

• Производительность WINDOW функций

• Производительность COPY• Затраты памяти на анонимные блоки (DO)• Улучшения оптимизатора

Небольшие но приятные мелочи

• Производительность WINDOW функций• Производительность COPY

• Затраты памяти на анонимные блоки (DO)• Улучшения оптимизатора

Небольшие но приятные мелочи

• Производительность WINDOW функций• Производительность COPY• Затраты памяти на анонимные блоки (DO)

• Улучшения оптимизатора

Небольшие но приятные мелочи

• Производительность WINDOW функций• Производительность COPY• Затраты памяти на анонимные блоки (DO)• Улучшения оптимизатора

Мониторинг

• pg_stat_all_tables.n_mod_since_analyze

• pg_stat_archiver

• backend_xmin

• Улучшен EXPLAIN

Мониторинг

• pg_stat_all_tables.n_mod_since_analyze

• pg_stat_archiver

• backend_xmin

• Улучшен EXPLAIN

Мониторинг

• pg_stat_all_tables.n_mod_since_analyze

• pg_stat_archiver

• backend_xmin

• Улучшен EXPLAIN

Мониторинг

• pg_stat_all_tables.n_mod_since_analyze

• pg_stat_archiver

• backend_xmin

• Улучшен EXPLAIN

Задел на будущее - параллелизм и логическая репликация

• пользовтельский С-код может исполняться как отдельниый процесс(background workers)

• Параллельная запись в буферы WAL• Logical Decoding