ComodoHacker: вот не помню точно, как именно innodb реализует index only scan для mvcc. Но кажется, что никак и вычитывать версию строки надо именно из данных. Соответственно, никакой индекс при этом как-то помочь не может - всё равно надо вычитывать.
Да, согласен, если count надо делать 1 раз по праздникам - это будет дешевле. Но если на одно написание комментария будет сотня просмотров списка статей - счётчик непосредственно в статьях более чем оправдан.
semki096: нет, вы спросили как раз про форк. Идею вы открываете сразу и безусловно при старте проекта, хоть с закрытым исходником хоть с открытым. Нельзя украсть опубликованную идею.
Лицензия, запрещающая форки - не знаю такой из распространённых. Скорей всего это будет кастомная лицензия.
Когда не укладываетесь в желаемую производительность - вот тогда и денормализовывать. Какую-то аггрегацию нередко оправдано добавлять сразу, как появилась необходимость её выводить на веб-морде, например, статистику чего-нибудь для графиков. Меняется только хвост, а начало статично. При том, таблиц аггрегации может быть и несколько. Это может быть и материализованное представление, когда наконец сделают инкрементное обновление - но тоже своего рода таблица. Теоретически, это денормализация, вот только для исходных данных нормальная форма остаётся как есть. Добавляется только предварительно рассчитываемый аггрегат.
В каком смысле, как его "Using"? Автоматическая оптимизация выполнения, вроде index intersect. Если запрос выполняется часто, то тюнить настройки памяти, чтобы необходимые данные были в кэше, а не читались с диска. Если explain с прогретой машинки, значит данные в буфера катастрофически не влезают и вытесняются слишком быстро.
Проверяйте конденсаторы. В первую очередь в блоке питания.
Хорошие модели у seasonic, enhance
Приличные у Corsair
Крепкие рабочие лошадки - FSP. Бывают несколько шумными и с короткими кабелями.
По остальным надо смотреть конкретные модели.
По мощности - без разгона 30-35А по +12В линиям за глаза хватит.
df - это смонтированные файловые системы, а не все блочные устройства. Смонтированные разделы os-prober и не будет пытаться монтировать.
От file странная реакция, утверждает, что это не разделы, а блочные устройства со своей таблицей разделов. И говорит, что MBR, но начинается со второго сектора - это странно.
По ответу похоже, что вы не только не знаете, как размечены ваши диски, но и что на них вообще находится.
Значит, если раздел не используется - его можно рассматривать как бинарный мусор и анализировать содержимое бессмысленно. Ну, os-prober этого не знает и пробует читать.
Вопрос-то в чём?
Что вызывает эти сообщения? Гипотеза дана. Грохните os-prober и проверьте.
В порядке ли ваши расходники - так расходники и проверяйте. man badblocks, smartmontools
Ну да, фактически всё время - это Planning time. Что с ним делать - не использовать много партиций и ждать. Конкретных релизов пока нет, но в сторону более нормального партицирования разработчики движутся.
А зачем вам партицирование вообще? Что хотите его использованием добиться? Основные причины:
- сокращение размера индексов
- простые и лёгкие удаление и очищение ненужных разделов
По второму пункту добавить мне нечего - с такими задачами не сталкивался, что нужно удалять много данных, часто и быстро.
По первому - можете использовать partial index https://www.postgresql.org/docs/9.4/static/indexes...
В том-то и загвоздка, что подобные, а не такая же и помногу раз в секунду, чтобы имело явный смысл запариться и считать на стороне СУБД. В следующий раз надо будет заменить что-нибудь другое в другом месте - и обработчик для этой задачи подойдёт чуть менее чем никак.
А знакомый язык, да с полноценными регулярками - простое и понятное решение. СУБД может помочь с предварительным фильтром, чтобы не обрабатывать данные, в которых подстроки и нет вообще.
Кого поставить на апач? Наверняка ваш nginx уже собран с этим модулем, как, например, в репозиториях debian. Вот и допишите в конфиг использование этого модуля. Ну а если не собран - то придётся пересобрать кастомный nginx.
