Привет все.
Собственно не знал даже как правильно назвать тему.
Опишу ситуацию.
Есть таблица которая содержит порядка 3000 - 5000 записей.
Если говорить о соотношении запросов к ней то : SELECT/INSERT/UPDATE 30%/60%/10%.
По сути, это "Ахиллесова пята" нашей архитектуры БД. И она очень хорошо себя проявила на прошлой версии системы которая была на MariaDB. Точнее еще и есть. Но время позволило создать новую архитектуру на Postgres, и не хочется снова наступать на теже грабли.
Опустим часть с индексами, оптимизированными запросами - поскольку они максимально простые.
Т.е остаются проблемы:
- конкретного доступа на уровне строк
- дисковая система
- мусор (vacuum)
Вариант с MEMORY не подходит по причине использования потокой репликации.

А теперь вопросы:
1. Насколько большая вероятность поймать deadlock или tablelock? И при каких обстоятельствах.
2. В партицировании я не вижу смысла, поскольку количество записей не большое.
3. Можно ли в Postgres вынести конкретную таблицу в отдельную директорию? на SSH например

И как вы бы подошли к организации подобной архитектуры?
Стремаюсь , поскольку в Mysql насмотрелся на висячие "Freeing item" и подобное. Ну там и железо было не ахти.

Заранее всем благодарен за мысли!!)

Maxim Boguk,
Спасибо. С инсертами там погорячился. их вообще очень мало будет и редко.
По поводу
авторсамое важное это чтобы длинных транзакций на базе у вас не висело при высокой активноси записи (иначе мусор будет быстро копится несмотря на autovacuum).


Вот это умная мысль. Т.е запросы которые используют JOIN данное таблицы, лучше вынести на уровень приложения.

Maxim Boguk,
Ну я это понял как:
Есть запрос:
SELECT .....
JOIN "та самая таблица"
JOIN table
JOIN table 1;

Т.е избегать подобных запросов.

Maxim BogukElectric200Maxim Boguk,
Ну я это понял как:
Есть запрос:
SELECT .....
JOIN "та самая таблица"
JOIN table
JOIN table 1;

Т.е избегать подобных запросов.

нет вы поняли не правильно...
я имел в виду
begin;
...
ушли курить на 10 минут или на 5 часов
commit;
вот так вот делать не надо...

а собственно сложность запросов никак не связана с этим.
Так и я о том же. Если вместо "курить" будет запрос минут на 10.

Maxim BogukElectric200пропущено...

Так и я о том же. Если вместо "курить" будет запрос минут на 10.\

запрос на 10 минут это надо постараться... хотя конечно возможно да.
Запрос может и нет, но хранимка легко.