mrWan, и чем же это вам упростило поиск ошибки? Вы это написали и вы этим не смогли воспользоваться никак. Вы даже не посмотрели, что вам возвращает функция, иначе ваш вопрос звучал бы совсем иначе.
В рабочем режиме тем более. Функция, выдающая в зависимости от фазы луны строку с результирующими данными или строку с описанием ошибки - это к проблемам.
longclaps, именно только для myisam. Для мультиверсионного транзакционника innodb вопрос "сколько у тебя строк" не имеет смысла вообще. Имеет смысл "сколько версий строк видит моя транзакция". И без проверки каждой строки на видимость в конкретной транзакции это не узнать. В статистике же хранится приблизительное число строк.
TrueNinja, а кто сказал, что в блоке питания нет проблемы? Симптоматика не характерная и только, а причиной быть по-прежнему может.
Температуры в норме - это в числах сколько? Раздельно по каждому ядру CPU, GPU и VRM
Думаю в этом контексте максимальным ограничением поддерживаемой памяти можно пренебречь
Это если не стоит выбор между двумя конкретными конфигурациями: с 32гб или 64 гб. В вопросе именно так описано, поэтому я не про максимальных поддерживаемый объём.
Базе нужна преимущественно память (но и ядра тоже), веб-серверу - в зависимости от качества написанного кода. Но параллелится нагрузка этого профиля хорошо.
Проглядел в тегах - похоже речь о VPS. Выясните у хостера - выделяются статично ядра физические или как повезёт и можно получить псевдоядра HT? И раз это VPS - то сколько в итоге дают вам ядер?
primary key в принципе не может быть null. auto_increment не может быть отдельно от первичного или уникального ключа. Подцепитесь штатным консольным клиентом и проверьте данные и show create table в консоли.
synchronous_commit в 8.4 уже был https://www.postgresql.org/docs/8.4/static/runtime...
Но перед выключением внимательно прочитайте что именно эта гайка делает. tradeoff между производительностью и риском потери последних коммитов при аварии.
huge pages - это к параметрам операционной системы. До 9.2 включительно можно было извращаться с libhugetlbfs. А вот начиная с какой версии можно было извращаться - хз. Впрочем до 32гб памяти можно не заморачиваться.
shared_buffers 32мб - это кошмар. Годится только если вы на каком-нибудь утюге запустились где всего 128-256мб памяти.
Чтобы понимать масштабы - postgresql будет обрабатывать данные только в shared_buffers. Чтобы сходить за данными в индекс - надо прочитать какие-то части индекса в shared_buffers (минимум 1 страничку корня btree, дальше как получится по запросу). Чтобы по полученным из индекса ctid сходить за данными - надо идти в таблицу, читать страницы в shared_buffers. И постоянно вытеснять другие страницы из shared_buffers. Потому что в 32мб можно поместить всего 32мб/8кб = 4096 страниц. Картину немного исправляет то, что postgresql использует системный файловый кеш. Но ходить настолько интенсивно в файловый кеш штука не бесплатная.
Наша в dataegret обычная рекомендация - отдельная машина только под базу, 25% RAM под shared_buffers. Т.е. никаких приложений на той же машине - иначе невозможно контролировать ресурсы. Какой-нибудь PHP случайно откушал на 20гб памяти и база в свопе - это из реальной практики. Если база влезает в память - то можно до 75% памяти отдать под shared_buffers.
Индексы - если кратко то всё сложнее. Ненужными индексами можно сделать хуже (особенно в зависимости от интенсивности записи). Писать ещё одно сочинение по тому как проставлять индексы настроения нет. Есть замечательный материал здесь: use-the-index-luke.com
Надо учитывать, что гайки и fsync и synchronous_commit - это для операций записи. Если много читаем с медленных дисков - они никак не повлияют на происходящее.
Что вы сделали для того, чтобы изменённые переменные окружения устанавливались заново при следующей авторизации пользователя? В PATH очевидно отсутствует место куда вы поставили бинарники базы.
Chvalov, по приведённому фрагменту не видно, что пространства имён не используются. Выведите var_dump(__NAMESPACE__); перед try, например.
Поймать всё что можно поймать - да, в php5 \exception, в php7 - \Throwable
Не во всех месяцах есть 31 день. И Postgresql об этом знает. Даже 29 день не всегда бывает. И об этом база тоже знает. И даст за такое безобразие как 31 ноября ошибку.
Выведите в notice переменные, посмотрите какие именно констрейнты создаются. Раз триггер ведёт себя странно - значит отлаживайте триггер.
Проще всего такое поймать если ходить в базу через баунсер в режиме пула транзакций. Где большим и заметным текстом написано: серверные prepared statements в пуле транзакций не поддерживаются. При том транзакционный пул выгоднее сохранения серверных prepared и потому рекомендация включить эмуляцию prepared statements в PDO (она дефолтно включена)
Explain запроса с одной таблицей так выглядеть не может. Либо вы показываете план не того запроса о котором говорите.
Плюс покажите show constraint_exclusion и (в psql) \d events2016m11 для примера того, что table constraint у вас есть.
В рабочем режиме тем более. Функция, выдающая в зависимости от фазы луны строку с результирующими данными или строку с описанием ошибки - это к проблемам.