ВЯ
ну это как-то сбоку было
Size: a a a
2020 May 21
ВЯ
там я не понял что с индексами
VY
Владимир Яворский
кто-нибудь знает, запили ли engine для postgresql для хранения колонками? типа clickhouse)
нет. Table AM сам по себе ещё нестабилен и сырой, плагинов нету. для 13-й версии больших изменений нет,
было сделано много рефакторинга и обсуждаются варианты дальнейшего развития
было сделано много рефакторинга и обсуждаются варианты дальнейшего развития
ВЯ
ое
ВЯ
а то меня попихивают время от времени на clickhouse(
ВЯ
а я упираюсь) жду аналогичного решения под pg
VY
https://www.postgresql.org/about/news/2040/ — все дружно побежали тестировать!
ВЯ
пусть даже не такого же эффективного... главное чтобы дешевле перехода на другой субд(
VY
в данный момент лучше смотреть на CH, PG ещё долго ждать
ВЯ
вы вообще за кого?))
ВЯ
в том то и дело что переходить без тестов глупо
ДЛ
база делает replay WAL-ов после аварийной остановки. или же она думает, что она реплика и должна накатить WAL-ы до точки консистентности
Да, это я уже понял. Тут вопрос, почему она накатывает логи со времён царя гороха.
Мы не дождались, переключились на реплику.
Но вопрос в том, почему основа так отстала. Может, в параметрах чекпоинта надо что-то поменять? Он не делался возможно?
Мы не дождались, переключились на реплику.
Но вопрос в том, почему основа так отстала. Может, в параметрах чекпоинта надо что-то поменять? Он не делался возможно?
ВЯ
а тесты нужны под 3ТБ данных(
VY
Да, это я уже понял. Тут вопрос, почему она накатывает логи со времён царя гороха.
Мы не дождались, переключились на реплику.
Но вопрос в том, почему основа так отстала. Может, в параметрах чекпоинта надо что-то поменять? Он не делался возможно?
Мы не дождались, переключились на реплику.
Но вопрос в том, почему основа так отстала. Может, в параметрах чекпоинта надо что-то поменять? Он не делался возможно?
возможно. также возможно что было огромное кол-во WAL-ов
а может ресурсов не хватает всё это оперативно обработать
а может ресурсов не хватает всё это оперативно обработать
VY
3TB в Postgres-е скорее всего будет меньше в CH. я за Postgres, но я реалист. если в 14-й версии будет хотя бы один Storage Plugin доступен — это дико круто!
ДЛ
возможно. также возможно что было огромное кол-во WAL-ов
а может ресурсов не хватает всё это оперативно обработать
а может ресурсов не хватает всё это оперативно обработать
А какие параметры влияют на частоту контрольной точки? Я правильно понимаю, что только этот?
checkpoint_completion_target
VY
А какие параметры влияют на частоту контрольной точки? Я правильно понимаю, что только этот?
checkpoint_completion_target
max_wal_size, checkpoint_timeout, checkpoint_completion_target из “явных”
ДЛ
max_wal_size, checkpoint_timeout, checkpoint_completion_target из “явных”
Чем меньше checkpoint_completion_target, тем чаще он делается же, верно?
Чем ближе к 1, тем реже..
Чем ближе к 1, тем реже..
VY
Чем меньше checkpoint_completion_target, тем чаще он делается же, верно?
Чем ближе к 1, тем реже..
Чем ближе к 1, тем реже..
нет. checkpoint_timeout — время между чекпойнтами, скажем 1 час (я меньше не ставлю).
checkpoint_completion_target — это проценты от сheckpoint_timeout (одного часа), за который чекпойнт должен выполниться.
0.1 — 6 минут, очень быстро, т.к. за 6 минут надо сбросить всё на диск. 0.9 — 54 минуты, хорошо, т.к. диски нагружены равномернее. я ставлю 0.9 обычно.
checkpoint_completion_target — это проценты от сheckpoint_timeout (одного часа), за который чекпойнт должен выполниться.
0.1 — 6 минут, очень быстро, т.к. за 6 минут надо сбросить всё на диск. 0.9 — 54 минуты, хорошо, т.к. диски нагружены равномернее. я ставлю 0.9 обычно.
ДЛ
Хмм...