avinogПоздновато я конечно сюда попал.

Мой опыт показал, что если архитектор системы идет на поводу у пользователей и пытается реализовать все их предложения, то на системе можно ставить крест :). Тем не менее выскажу идеи, реализация которых, на мой взгляд, может дать существенное конкурентное преимущество (в порядке убывания актуальности).

1. Возможность приоритезации операций ввода/вывода для различных пользователей
Скажем, есть пользователь, операции которого должны выполняться как можно быстрее. Его запросы определяют работоспособность системы в целом. Например в телефонии, это будут запросы связанные с идентификацией, авторизацией, маршрутизацией, горячим биллингом. Но запросы связанные с генерацией отчетов, выставлением счетов, должны выполняться в "фоновом" режиме.
"Дождливый" селект должен приостанавливаться, если во время его исполнения поступил более приоритетный запрос.

В Оракле есть возможность выставить приоритеты пользователям для доступа к процессору системы, но эта возможность бесполезна, поскольку узким местом, как правило, является не вычислительная мощность системы, а операции ввода/вывода. Установив, скажем пользователю квоту в 1% процессорного времени проблема решена не будет. Эта квота будет играть роль, только тогда, когда проц загружен больше 99%, а если он загружен на 30%, то при поступлении низкоприоритетного запроса, система выделит ему все свободные 70%, что совершенно правильно.

Система не должна вставать на колени, если несколько менеджеров одновременно приступили к созданию отчетов.

2. Отмена требования по удалению объектов, зависимых от модифицированного объекта
Согласитесь, было бы странно, если бы при модификации таблицы (добавление/удаление столбца, изменение типа данных) или даже при ее удалении (при пересоздании), система бы требовала удалить все хранимые процедуры и объекты, зависящие от неё.

Но это считается нормальным при работе с объектами. В результате, крайне ограниченное их использование (только при полной безысходности) в силу чрезвычайного неудобства работы с ними. Если так сделано в Оракле, то это совсем не значит, что также должно быть сделано и в PG.

3. PL/PgSQL. Реализация возможности циклического перебора элементов записи или атрибутов объекта
Что-то подобное этому:

а еще лучше осуществить доступ к ним по "индексу".

Редко, но бывает нужно, при построении гибких систем, особенно, когда у заказчика исторически имеются таблицы с числом колонок больше сотни. Конечно, последовательный доступ к колонкам можно получить, используя имеющиеся средства, но все это настолько криво, а посему очень медленно...

1)ionice в кроне раз в минуту и разделение отчетных и приоритетных пользователей + pgbouncer чтобы коннекты жили эту проблему более менее решает. Отчеты живут с ionice -c 3 (вместе с autovacuum/pg_dump и прочими некритичными к скорости IO вещами).
Но вообще использование ssd делает эту задачу малоактуальной.

3)вероятно не будет сделано никогда так как target_tanyelement не может иметь разные типы... pl/pgsql архитектурно не умеет работать с полиморфными переменными (и не будет уметь). Так что я бы на это не расчитывал. Да и hstore workaround не такой уж ужасный на практике.

avinogМаксим, спасибо за советы и оперативный ответ.

Maxim Boguk1)ionice в кроне раз в минуту и разделение отчетных и приоритетных пользователей + pgbouncer чтобы коннекты жили эту проблему более менее решает. Отчеты живут с ionice -c 3 (вместе с autovacuum/pg_dump и прочими некритичными к скорости IO вещами).
Но вообще использование ssd делает эту задачу малоактуальной.
В свое время эту задачу пытались решить для Оракла путем использования ionice для задания приоритетов процессам ввода/вывода - неудачно. Для этого необходимо связать процессы ввода/вывода с пользователями, а они принадлежат одному пользователю - Oracle. Может в отношении PG я ошибаюсь. Наконец, есть еще виндовые пользователи.
И pgbouncer не поможет. Достаточно пары "красивых" селектов.

Короче, система должна быть удобной.


crontab -l
...

* * * * * ps -u postgres x | grep -E 'autovacuum|COPY|pg_dump|cron_role|report_role' | grep -v grep | perl -pe 's/^\s*(\d+) .*$/$1/' | xargs --no-run-if-empty -I $ ionice -c 3 -t -p $

куда уж проще то...

+ pgbouncer чтобы коннекты от cron_role и report_role жили более менее перманетно с выставленным ionice уже...
пользуюсь тем что в ps -u postgres x есть имя пользователя подключенного к базе

29841 ? Ss 0:07 postgres: cron_role somedb [local] idle
30072 ? Ss 0:04 postgres: report_role somedb [local] idle
...

Таким образом в 99% случаев любой запрос от cron_role или report_role уже идет с низким IO priority


PS: windows + Pg в production использовать НЕ НАДО.