Мне казалось, что сырые данные надо агрегировать, пред обработку делать а потом сохранять

консервативный взгляд)

brin index и если логика позволяет, то не заводить primary key

timestamp заместо примари?

ну есть горячие данные,есть холодные, которые уже никогда не нужны

консервативный взгляд)

Ну я доку по кликхаусу почитал, подумал, что его можно а связке с пг юзать

timestamp заместо примари?

угу и по нему brin. Тогда индекс будет маленький и без замедления при увеличении таблицы

ну есть горячие данные,есть холодные, которые уже никогда не нужны

А какой срок у горячих данных?

несколько месяцев

несколько месяцев

Тогда партиции, по времени

Тогда партиции, по времени

https://www.postgresql.org/docs/9.6/static/ddl-partitioning.html

я документацию смотрю, там получается, что таблицы для партицирования статичные

https://www.postgresql.org/docs/9.6/static/ddl-partitioning.html

https://github.com/postgrespro/pg_pathman

сложна :(

крайне надеялся , что как в hive можно было бы сделать

крайне надеялся , что как в hive можно было бы сделать

Мяу сложно?

Space Dandy :)

сложна :(

Вся жизнь сложная

https://github.com/postgrespro/pg_pathman

Таки можно и же через косиыль с триггерами

имхо сложнее...

Мяу сложно?

Оч сложно после Хайва

Господа, кто-нибудь сталиквался с PSQLException: ERROR: invalid page in block ?

да

почитал стековерфлоу

что можете посоветовать?

в пм

у меня есть две таблицы с данными, из них надо сделать два диффа: из первой во вторую и из второй в первую, инсертами, апдейтами и делитами есть ли готовые тулзы для этого?

ишь. данные/поля же всегда разные у всех

у меня есть две таблицы с данными, из них надо сделать два диффа: из первой во вторую и из второй в первую, инсертами, апдейтами и делитами есть ли готовые тулзы для этого?

pg_dump —inserts + diff не поможет?

мне миграцию и её реверт для продакшена написать :) алгоритм расчёта таблицы неинкрементальный

да, сейчас так и делаю. раньше были только инсерты, теперь вот апдейты появились :)

хотя, апдейты можно расписать в delete/insert. но тогда проблема гарантировать, чтобы insert шёл за delete в диффе

готовой утилиты для подобного не встречал...

готовой утилиты для подобного не встречал...

https://lxadm.com/PostgreSQL:_ERROR:_invalid_page_header_in_block_13760_of_relation_base/16995/67484

вот нарыл

стендбай есть у вас

?

нет

это плохо

тогда zero_damaged_pages = on и vacuum можно еще пересоздать таблицу без проблемных записей (если есть откуда проблемные запписи восстановить, то их залить после) ну и разобраться с проблемами с дисками

что это за объект хоть посмотрите, может повезет и это индекс, тогда реиндекс

Как можно обновить булево значение, расчитав его в самом запросе, например: UPDATE scrapper_task SET done = (total == processed) WHERE id = 4 RETURNING *? На таком запросе получаю ошибку: operator does not exist integer = integer.

set done = (total = processed)

=> update table set some_id = (id = user_id)::int ; UPDATE 2582 например

можно еще case влепить

set done = (total = processed)

Спасибо!

https://github.com/postgrespro/pg_probackup/releases/tag/v1.0 никто попробовать не хочет?

А вот про проверку консистентности вопрос... Он только чексуммы проверяет. А если мы удалим часть файлов в бд, он промолчит? В системном каталоге есть инфа о том, какие файлы есть в БД?

А вот про проверку консистентности вопрос... Он только чексуммы проверяет. А если мы удалим часть файлов в бд, он промолчит? В системном каталоге есть инфа о том, какие файлы есть в БД?

проверь, удали ))

Я у Юрия спрашивал

я просто совет дал ))

Если у ВАС есть что сказать по делу, то скажите.

Дело в том, что я уже удалял. PostgreSQL спокойно стартует при удаленных файлах. Вы не знаете, что у вас date loss пока не обратитесь к данным из удаленных файлов. И это очень расстраивает.

every day I'm dumping

А вот про проверку консистентности вопрос... Он только чексуммы проверяет. А если мы удалим часть файлов в бд, он промолчит? В системном каталоге есть инфа о том, какие файлы есть в БД?

на самом деле можно получить к этому доступ. но вот сколько страниц у тебя в relation - никто не знает, в pg_class только статистика

серьезно, а как же дамп ежедневный?

Да. Пока это единственный выход.

а дамп тебе индекс искареженный найдет?

а данные extensions?

pg_compactor с реиндексом

принудительный

легализует половинные файлы

Индекс можно перестроить. А потерянные полгода (10 лет назад) назад данные, бэкапы которых уже тю-тю, нет

релейшены от которых потеряны файлы

ну и да, поиметь проблемы с индексом не там печально, как иметь проблемы с данными

а тебе важно что ты обнаружишь потом проблему и востановишь или что у тебя приложение с хер пойми чем поработало?

так оно работать не будет же, если индекса нет, по мониторингу логов все будет понятно

Мне важно, что система бэкапа при бэкапе скажет, что я не буду бэкапить битую БД. Как rman, например

error логи же на почту сыпятся

ERROR: S client not available

дык слава богу если посыпяться, вопрос в том, чтобы pg не молчал

а так ведь молчит сука о потерянных страницах в файлах

Да при чем тут индексы? Они только косвенно скажут, что есть битые линки. И то, ТОЛЬКО при обращении потеянным данным

А вот про проверку консистентности вопрос... Он только чексуммы проверяет. А если мы удалим часть файлов в бд, он промолчит? В системном каталоге есть инфа о том, какие файлы есть в БД?

Если удалим часть файлов БД то проглотит. У postgres с этим есть проблеммы но мы уже над этим работаем, правда в рамках pgpro или даже pgproee.

т.е. система бекапа тут только частично может помочь по этому мы решили решить проблемму принципиально

pg_probackup это утилита которая сама лезет к файлам, сама разбирает страницы и т.д. и смотрит она на postgres как на каталог с файлами. (конечно она запускается start/stop backup и т.д.)

К слову pg_probackup поддерживает бекап с реплики для 9.6

А какие идеи есть в эту сторону. В ораклах для этого controlfile имеется. Либо каталог в отдельной БД для восстановления

А какие идеи есть в эту сторону. В ораклах для этого controlfile имеется. Либо каталог в отдельной БД для восстановления

иметь актуальную информацию о сегментах

А какие идеи есть в эту сторону. В ораклах для этого controlfile имеется. Либо каталог в отдельной БД для восстановления

в каталоге

Т.е. в системном каталоге списка файлов нет? А как они тогда связаны с друг с другом? Как связный список? Но ведь тогда припотере среднего файла весь хвост отвалится?

Т.е. в системном каталоге списка файлов нет? А как они тогда связаны с друг с другом? Как связный список? Но ведь тогда припотере среднего файла весь хвост отвалится?

нету никакой связи вообще, наличие следующего сегмента он определяет так - поробуем ка открыть файл с номером сегмента +1 если смогли значит есть

в постгресе тоже есть control file pg_control называется

Т.е. в системном каталоге списка файлов нет? А как они тогда связаны с друг с другом? Как связный список? Но ведь тогда припотере среднего файла весь хвост отвалится?

и нету никакого списка файлов, в лучем случае есть список релейшенов которые могут быть представлены несколькими сегментами + ещё есть LRU различные о которых никто не знает

в постгресе тоже есть control file pg_control называется

только он о другом

только он о другом

Так о чём и речь...

т.е. интроспекции никакой

в постгресе тоже есть control file pg_control называется

я думаю что это сложно

Хорошо. Я ответ на свой вопрос получил. Спасибо :)

Хорошо. Я ответ на свой вопрос получил. Спасибо :)

Плохо. Но скоро станет куда лучше. :)

Хорошо. Я ответ на свой вопрос получил. Спасибо :)

Уже сейчас в probackup можно проверить что те файлы релейшенов что в наличии не повредились, других таких средств просто нету в мире.

Уже сейчас в probackup можно проверить что те файлы релейшенов что в наличии не повредились, других таких средств просто нету в мире.

не правда, есть базы, которые имеют встроенную проверку целостности :D

на ленту, я так понимаю, pg_probackup писать не умеет?

не правда, есть базы, которые имеют встроенную проверку целостности :D

я про postgres

про утилиты для postgres

на ленту, я так понимаю, pg_probackup писать не умеет?

нет но можем научить, пока всё не можем найти когонибудь с таким комплексом что бы всё подогнать

мы пишем бакулой, но было бы круто иметь сто-то специальное, как типа oracle secure backup, но для пг

мы пишем бакулой, но было бы круто иметь сто-то специальное, как типа oracle secure backup, но для пг

я думаю что криптовать сложно

простите тролю

да хотя бы что-то без криптования пока))

а можете точное название написать этой дракулы?

bacula?