Melkij

Логический дамп быстрым не будет. Возможно вам нужен физический бекап, возможно отстающая реплика. Смотря что хотите получить.

Ну а по логическому дампу - записать данные и построить индексы или добавить индексы, а потом писать данные - две очень большие разницы.
Поскольку речь о статистике - нарежьте статистику на партиции, можно в отдельный schema их пихнуть для удобства. Основную базу соответственно дампите с исключением данных партиций, затем заполняете разделы данными и пристёгиваете их к основной табличке. Или, что лучше, дампите в более подходящие format custom или directory всю базу, затем восстанавливаете параллельно с --exclude-schema и отдельно разделы статистики.

Никак.

Взять исходные данные с которых был получен этот хэш, посчитать ещё раз, затем сравнить.

SHA1 даёт ровно 160 бит информации. Никакой формы идентификации, избыточности или crc стандартом не предусмотрено.

Потому что это разные запросы. Соответственно:

WHERE id IN ('104,106')
WHERE id IN (104,106)

Первый из-за мягкой системы типов mysql тихо превращается во что-нибудь интересное вроде id = 104 с незаметным варнингом от парсера mysql

Вероятно вы путаете понятия база и таблица. Иначе непонятно, что вы имеете в виду говор о FK между базами.

Если цель оптимизировать занимаемое место для явно timeseries данных - то и используйте timeseries базы.
Полновесный версионник с 23 байтами оверхеда на один только заголовок каждой строки (ещё не начиная считать данные, плюс выравнивание структур) сильно сомнительно что окажется компактнее ориентированных на timeseries данные базы.

Зачем вам Portage SQL вообще в винде?
Наверное, речь всё-таки о PostgreSQL.

Сравнение двух таблиц - банальный стандартный FULL OUTER JOIN

select * from t1 full outer join t2 using(id) where (t1.*) is distinct from (t2.*);

Сравнение баз - вероятно удобнее будет чем-то внешним.

SSD берут ради скорости, тем более внятные на запись серверные SSD.
RAID5 или 6 ставят ради стоимости хранения гигабайта ценой заметного ущерба производительности записи.
То есть не очень понятно, с какой целью вы рассматриваете 5 или 6 рейд на хороших SSD. Если важен объём - то берите более дешёвые S45xx

и вообще у кого есть опыт использования ssd в рейдах на длительный срок(3-5 лет) как себя ведут ssd

Intel - отлично себя ведут. Даже при проблемах с питанием, у них штатный конденсатор, держащий достаточно энергии для корректной записи всего что диск пообещал системе. В спеках описано как Enhanced Power Loss Data Protection
У нас в эксплуатации много intel'ов разных лет (давно за сотню штук) Меняли в основном потому что в объём упирались. С отказом диска встречались только один раз. И это всё в условиях под постоянной нагрузкой СУБД postgresql.
В общем, мы безоговорочно рекомендуем брать в сервера интеловские SSD (если получается) за надёжность и предсказуемый latency под нагрузкой. Другие диски - очень сильно по разному себя ведут.

2) исходя из вопроса, есть смысл делать рейды 5 или 6 если все равно на все ссд пишется сразу данные ? получается к концу обьема записи ssd придется менять все диски сразу если какой раньше не вышел из строя

Я не вижу смысла в 5/6 рейдах на хороших SSD не касаясь Lifetime Writes

1) в этом контроллере есть hp smartpath, при его включении линейные скорость значительно ниже, примерно в 2 раза нежели при включении встроенного кеша, имеет смысл его вкл(smartpath или выключать) ?

Лучше softraid. Серьёзно. Без шуток. Глупый HBA и softraid.
hardraid под хорошие SSD надо или очень пристально настраивать хорошо зная свой контроллер или вы будете упираться в производительность контроллера, а не в диски.
PS: зачем вам линейные скорости под базы и виртуалки? Тестируйте random io.

Память формата DDR2 SDRAM должна уметь работать на напряжении 1.8V +/- 0.1V. Иначе она не может называться DDR2 SDRAM - это стандарт JEDEC.

select lexeme, count(*) from tabledata cross join unnest(to_tsvector(data)) as lexemes group by 1;

?

gin_trgm_ops - НЕ полнотекстовый индекс и не производит деление по словам. Это pg_trgm extension с реализацией триграмного поиска. Имеет отношение к тексту, но совсем не fulltext search.

Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given

Что именно неясно в ошибке сказано? Параметр должен быть чем-то похожим на DateTimeInterface, а вы bool пихаете.
Откуда bool - потому что date_create_from_format его имеет право вернуть. В частности, если формат строки не соответствует требуемому.

Ну и не имеет смысла дёргать форматирование в строку и повторно strtotime, когда уже есть родной метод getTimestamp.

linux ate my ram!/

1686мб доступно. См. available в выводе free.

И память kvm виртуалки с хоста мониторить невозможно. Хост ожидаемо видит, что гость использует всю память.

Смотрите explain (analyze, buffers), сильно желательно с включенным track_io_timing. Почти наверняка первый запрос вы читаете с диска, второй - уже из shared_buffers. Либо с page cache операционной системы.

чтобы они были согласованные

при сбое одного из серверов, БД смогла работать и не нужно было руками проверять согласованность.

У пользователя 100 рублей на счету. У вас упала сеть между серверами баз.
Пользователь хочет потратить 100 рублей.
Что дальше?
- запрещаем тратить пока не починим - вот это CP система. Мы в readonly, но все данные корректны, к какой базе бы не обратились. Синхронная репликация в основном
- разрешаем потратить только на одной базе, вторая - readonly и соответственно может показывать отстающие данные. Но работает. Это любая СУБД умеющая master-slave репликацию. Реплика догонит состояние мастера непротиворечиво и самостоятельно когда почините сеть
- разрешаем запись на обоих серверах. Пользователь нажал "купить" дважды, запросы случайно попали на разные сервера. Сеть починили - как соединять данные? Две покупки и -100 на счету? Какая-то одна покупка? Как это решать автоматически, да ещё на уровне СУБД, а не бизнес-логики?