Melkij

Нужно чтобы у каждого пользователя была как бы отдельная база данных.

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

Между предложениями нет никакой связи, уж тем более причинно-следственной.

Для начала ответьте, по каким соображениям вы решили отбросить обычную нормальную форму (это технический термин) с добавлением к сущностям поля со ссылкой на владельца.

Суть такова, что есть прайс(ы) ~5млн и его нужно быстро обновлять (раз в 2 часа).

Это НЕ много и совсем НЕ часто.

обновлять или удалять и заново записывать

Ложный выбор, это одна и та же операция. MVCC update = delete + insert
Но что важно - не делать update который вам действительно не нужен. Postgresql не анализирует данные в поиске пустых обновлений, update table set id = id; вам честно удвоит таблицу, хотя ничего на логическом уровне не изменится.

Профилируйте, на что реально тратите время - pg_stat_statements ответит хорошо на этот вопрос со стороны базы. Пальцем в небо - вы работаете в автокоммите и естественно 5млн пишущих операций для любой честной ACID базы - это порядком медленного IO (даже для SSD)

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

Ну а по логическому дампу - записать данные и построить индексы или добавить индексы, а потом писать данные - две очень большие разницы.
Поскольку речь о статистике - нарежьте статистику на партиции, можно в отдельный 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.