Раньше был вариант сходить в налоговую с 3 дюймовой дискеткой , а лучше с 2-мя (мало ли одна не прочитается) забрать dbf - ки самому) С тех пор структура файлов не менялась) А сейчас можно скачать, прогресс...
Новость из разряда мы опять вам все сломали) Хотите использовать последнюю версию переделайте 60% кода старой. Что за подход? Но видимо сейчас это модно. Наберут по объявлениям команду, которой в лом поддерживать старый код. А давайте переделаем все без обратной совместимости…
Судя по вашим рассуждениям видно что вы никогда не мигрировали с одной версии на другую, более менее приличный объем данных. Без остановки продакшена на сутки и более… К тому же эта чудо утилита то же достаточно странно работает. А когда разница между версиями 3 мажорных релиза, не известно как она отработает. Чего стоит переименование всех функций относящихся к wal и самих журналов, все критичные изменения не вспомню. Но из за этих мониторинг пришлось в срочном порядке допиливать.
pglogical для копирования синхронизации таблиц это тот еще инструмент. Не знаю как сейчас, а в свое время при попытке попользоваться им при миграции с 9.5 на 10. Вышло все печально, просто впустую потраченное время 2 суток на таблицу в 1,7ТБ, потом стало заканчиваться место на диске и пришлось это безобразие остановить. Взять londiste и без проблем перенести данные за вменяемое время. Без ужимок и прыжков с логами, ошибок в них от этой чудесной штуки. И снежного кома не удаленных wal журналов, которые в итоге чуть не остановили сервер(linux если выбрать место на диске в 0 перестает отвечать). Не рассчитана она на более менее приличный объем данных. Мне повезло, вовремя заметил что места почти нет и остановил репликацию. 4 ТБ wal журналов это круто, т.е. не удалялись журналы с начала репликации.
Все хорошо и красиво пока на таблице, которую надо секционировать не висит 10 индексов часть из которых уникальные. Даже не беря в учет первичные ключи. Сомнительное удовольствие создавать руками весь набор ключей для секции, вместо того чтоб унаследовать это все у мастер таблицы. Сложность написания триггера тоже как то сильно преувеличена. Возможность не думать о создании ключей, кратно перекрывает удобство не писать триггер. А отсутствие первичных ключей у секций, вообще ставит под вопрос полезность такого секционирования в 10-ке по крайней мере.
Декларативное партицирование закладывает хороший фундамент для будущих улучшений в этой области. Есть надежда, что существующие проблемы уйдут в прошлое, и будет меньше головной боли с партициями.
То что сделано сейчас имеет весьма сомнительную ценность. На мастер таблицу нельзя навесить триггеры (уровня строки делающие проверки на on conflict например), индексы и все прочее добро. При создании партиций соответственно наследуется только структура, все что можно было унаследовать при триггерном партиционировании от мастера теперь надо прикручивать руками. В том числе и первичные ключи. Для создания годовалой секции это может и не критично. Но если это делать ежедневно, то будет напрягать. Особенно количество триггеров. На каждую секцию свой, вместо 1-го на мастер таблице. А пока к сожалению убрав одну проблему, сделали 10 новых. Остается ждать что может что нибудь изменится в подходе к партиционированию, а пока использовать старые методы. То что имеем сейчас, мало пригодно для использования в условиях ежедневного создания секций по нескольким десяткам таблиц. И предобработкой данных перед вставкой. Хотя для меня казалось что очень логично вешать триггер на мастер таблицу и применять его ко всем партициям.
В принципе идея фитофильтра (это так у нас аквариумистов называется изложена верно), только проблема в том что не всякое растение переносит постоянный ток воды и нахождение в ней 24 часа в сутки. Не знаю как базилик, а комнатные растения очень не многие выживают в таких условиях.
Видно что человеку нечем заняться и у него масса свободного времени. Вместо того чтоб написать нормальный SQL запрос или хранимую процедуру, написать JS класс который на клиенте занимается тем, чем должен заниматься сервер. Запрос select * считается дурным тоном если в таблице более 2-3 -х полей, а при JOIN и подавно.
Проблема была постоянной, если бы это был разовый запрос , а потом все нормально, то никто бы даже не стал искать причину.
Раньше был вариант сходить в налоговую с 3 дюймовой дискеткой , а лучше с 2-мя (мало ли одна не прочитается) забрать dbf - ки самому) С тех пор структура файлов не менялась) А сейчас можно скачать, прогресс...
То что сделано сейчас имеет весьма сомнительную ценность. На мастер таблицу нельзя навесить триггеры (уровня строки делающие проверки на on conflict например), индексы и все прочее добро. При создании партиций соответственно наследуется только структура, все что можно было унаследовать при триггерном партиционировании от мастера теперь надо прикручивать руками. В том числе и первичные ключи. Для создания годовалой секции это может и не критично. Но если это делать ежедневно, то будет напрягать. Особенно количество триггеров. На каждую секцию свой, вместо 1-го на мастер таблице. А пока к сожалению убрав одну проблему, сделали 10 новых. Остается ждать что может что нибудь изменится в подходе к партиционированию, а пока использовать старые методы. То что имеем сейчас, мало пригодно для использования в условиях ежедневного создания секций по нескольким десяткам таблиц. И предобработкой данных перед вставкой. Хотя для меня казалось что очень логично вешать триггер на мастер таблицу и применять его ко всем партициям.