это вы очень сильно заблуждаетесь, вероятно не застали тот исторический переход Prescott на Core архитектуру почти 12 лет назад. Первое из гугла: www.thg.ru/cpu/core_2_duo/print.html высокочастотные Prescott, даже топовые двухядерные EE в 3,7ггц частотой в принципе никак не могли соперничать даже с младшими core 2.
postgresql умеет стандартный filter для аггрегирующих функций. count(*) filter(where message='Купил Lada')
Что то же самое что и 'SUM(CASE WHEN (message='Купил Lada') THEN 1 ELSE 0 END)' но как-то нагляднее.
-Fc формат pg_dump должен начинаться с PGDMP в первых 5 байтах.
Этот флаг нужен для снятия custom формат дампа, там не sql, а структуры, которые умеет читать pg_restore. Есть ряд плюсов относительно plain text.
Аж H55 и "скорее всего не поддерживает AHCI"? Это в чипсете-то от автора самого AHCI? AHCI, который нативно умела аж давно похороненная виста? Умеет, конечно. В биосе есть переключалка, в секции 2-6 мануала описана.
Посмотрите через lsof дескрипторы deleted, похоже у вас что-то удалено, однако какой-то процесс держит дескриптор на эти файлы и потому они ещё не могут быть свободным местом в df, но уже не видны для du.
А вы перенастраивали директорию базы на старой системе? У убунт дефолтно PGDATA размещён в /var/lib/postgresql/(major pg version)/main - и для старта нужна вся эта директория целиком со всеми симлинками. Основное что могло быть вынесено отдельно - pg_wal/pg_xlog и симлинки из pg_tblspc
Поскольку речь о нерабочей системе - то конечно сохранить отдельно ещё одну копию PGDATA (а лучше всего /var/lib/postgresql/ и симлинков внутри) куда-нибудь в безопасное место.
Ну и разумеется major версия postgresql должна быть та же самая. datadir от 9.6.х не запустится на бинарниках 10.х и это специально так.
NogerbekNurzhan, и в чём же вопрос? Ответьте зачем вам хранить отдельно.
- глупое приложение не умеет писать where? Ок, сгодится. Вам нужен view. View в принципе не может быть не синхронизирован с таблицей. Потому что это view.
- если у вас хотя бы пара сотен гигабайт данных в табличке - тогда я могу понять, зачем гипотетически может быть нужно именно хранить отдельно. Но сомневаюсь, что партицирование по статусу при этом осмысленно. При том само поле статуса в таблице отчётов с ощутимой вероятностью свидетельствует о том, что это какая-то очередная самописная очередь в базе непригодная к работе под нагрузкой и развалится на смешных сотнях rps.
- тараканы насоветовали? А чем аргументировали эту странную необходимость?
Это не консольное phpinfo, это веб версия phpinfo который я вывожу в laravel.
Так я вижу, что это веб версия. Потому и спрашивал именно
а консоль использует тот php.ini который правите? Обычно это два разных конфига.
Вопрос далее: тот php который вы вызываете для миграций и тот, с которого часть вывода php -i вы показали - это точно один и тот же php? Потому что у вас тут явно всякие докеры понамешаны.
ganjo888, стоит использовать обращение по нику, оповещения в комментариях без него нет. Вспомнил увидев ваш вопрос на ru.so
Картинка никак не отвечает на мой вопрос. Или объясните, как у вас консольный phpinfo вывел что-то до удивительного похожее на веб-версию phpinfo. Иначе говоря, смотрите php -i
Если в логе базы на debug5 пусто - то база или выключена или вы смотрите не тот лог.
Аналогично по заббиксу - если на debug уровне в ответ на действия ничего нет - вы смотрите не там. Не знаком с кодом заббикса, но тишины на debug логировании быть не может, иначе этот уровень логирования бесполезен даже самим разработчикам и должен быть удалён.
