Борис [А-Я][а-я]+, у sqlite нет хоста, логина и пароля.
Я. к своему счастью, не учитель в школе. Посмотрите в документации к вашему интерпретатору и к вашей ОС где приложение может создать файл для своей работы. Путь к некоторому файлу в этом месте и укажите в подключении sqlite.
Борис [А-Я][а-я]+, нет, а зачем вам питон для тренировки sql?
Что ж, если у вас на телефоне уже есть интерпретатор python - то используйте опять же sqlite.
Дмитрий, потому что на вид очень похоже на распространённую ошибку, когда зачем-то делают бессмысленный суррогатный ключ вместо родного составного ключа предметной области. У меня очень большое подозрение что здесь нужен первичный ключ (factor_id, parcel_id) и вовсе не нужное ни для чего поле id.
если мой хрустальный шар затуманился и это вдруг не эта ошибка, а все три поля действительно осмысленно нужны - то и хорошо.
Дмитрий, ммм, а куда подробнее? Этот id здесь действительно нужен? Ответ "ну ведь это primary key" не принимается. primary key вовсе не обязан быть суррогатным автоинкрементом
посмотрите в документации.
В вопросе синтаксис верен. Я процитировал два фрагмента из вопроса чтобы показать непосредственную ошибку. Присмотритесь к именам функций.
Запорожченко Олег, https://ru.stackoverflow.com/a/779716/203622
если дадите ФС и сеть хоста - то cgroups работают вполне нормально. От меня оооочень большой вопрос именно в "это будет более удобно с точки зрения администрирования". В чём это мифическое удобство для лишь только пары пакетов из репозитория с бинарниками базы и большим набором вопросов в сопровождении - от адептов докера я так и не услышал ответа. В чём смысл тащить лишнюю прослойку?
Для проверки доступности роутерами друг друга выбрана сеть 10.10.10.0/24
микротик разве это умеет? Насколько знаю нет, только одна настройка интерфейса vrrp - этот же интерфейс и будет использован для virtual IP и по этому же интерфейсу и будут ходить heartbeat пакеты.
Я правильно понимаю, что в итоге это будет выглядит так:
да, верно
Ну систему может и нет, а помешать работе ПО наверное может?
Переполнение любого раздела вероятно может помешать работе ПО, разве нет? Раз туда что-то писалось - значит это кому-то было нужно
Для гипервизора - да, я за использование lvm поверх raid. Система на LV томе; диски виртуальных машин - как LV тома, что эффективнее чем в виде файлов на файловой системе. И даёт гибкость управления.
Причем если не получиться запихать его в LVM, то вынести его за пределы LVM но оставить на обоих массивах(в случае с RAID1)?
под /boot нужны копейки места, можно хоть даже собрать raid1 из партиций от каждого диска.
Или выбрать что загрузочные диски - некая такая-то пара, сделать на них по небольшому разделу, поверх собрать mdadm массив, поверх массива - файловая система монтируемая в /boot
output plugin точно знаю у нас встречается wal2json
вероятно можно использовать штатный (начиная с postgresql 10) pgoutput - как раз он используется в штатной логической репликации и со стороны базы можно будет рулить именно штатными подписками.
В эксплуатации - лишь бы кто-то вычитывал данные и отчитывался об этом. Неиспользуемый слот логической репликации помимо безграничного накопления WAL так же будет мешать автовакууму работать.
Вы уже так и сделали. Ну и сделайте прямой индекс по балансу.
Как легко заметить, сама сортировка вам на самом деле ничего не стоит.
А вот чекпойнтер и bgwriter не справляются.
А так же на bitmap не хватает workmem. И, подозреваю, shared_buffers
Ну и ради всего 2.3 млн строк потрогали почти 12гб - с автовакуумом проблема точно.