avinogПоздновато я конечно сюда попал.
Мой опыт показал, что если архитектор системы идет на поводу у пользователей и пытается реализовать все их предложения, то на системе можно ставить крест :). Тем не менее выскажу идеи, реализация которых, на мой взгляд, может дать существенное конкурентное преимущество (в порядке убывания актуальности).
1. Возможность приоритезации операций ввода/вывода для различных пользователей
Скажем, есть пользователь, операции которого должны выполняться как можно быстрее. Его запросы определяют работоспособность системы в целом. Например в телефонии, это будут запросы связанные с идентификацией, авторизацией, маршрутизацией, горячим биллингом. Но запросы связанные с генерацией отчетов, выставлением счетов, должны выполняться в "фоновом" режиме.
"Дождливый" селект должен приостанавливаться, если во время его исполнения поступил более приоритетный запрос.
В Оракле есть возможность выставить приоритеты пользователям для доступа к процессору системы, но эта возможность бесполезна, поскольку узким местом, как правило, является не вычислительная мощность системы, а операции ввода/вывода. Установив, скажем пользователю квоту в 1% процессорного времени проблема решена не будет. Эта квота будет играть роль, только тогда, когда проц загружен больше 99%, а если он загружен на 30%, то при поступлении низкоприоритетного запроса, система выделит ему все свободные 70%, что совершенно правильно.
Система не должна вставать на колени, если несколько менеджеров одновременно приступили к созданию отчетов.
2. Отмена требования по удалению объектов, зависимых от модифицированного объекта
Согласитесь, было бы странно, если бы при модификации таблицы (добавление/удаление столбца, изменение типа данных) или даже при ее удалении (при пересоздании), система бы требовала удалить все хранимые процедуры и объекты, зависящие от неё.
Но это считается нормальным при работе с объектами. В результате, крайне ограниченное их использование (только при полной безысходности) в силу чрезвычайного неудобства работы с ними. Если так сделано в Оракле, то это совсем не значит, что также должно быть сделано и в PG.
3. PL/PgSQL. Реализация возможности циклического перебора элементов записи или атрибутов объекта
Что-то подобное этому:
1.
2.
FOR target_tanyelemen IN [record|object] LOOP
...
END LOOP
а еще лучше осуществить доступ к ним по "индексу".
Редко, но бывает нужно, при построении гибких систем, особенно, когда у заказчика исторически имеются таблицы с числом колонок больше сотни. Конечно, последовательный доступ к колонкам можно получить, используя имеющиеся средства, но все это настолько криво, а посему очень медленно...
1)ionice в кроне раз в минуту и разделение отчетных и приоритетных пользователей + pgbouncer чтобы коннекты жили эту проблему более менее решает. Отчеты живут с ionice -c 3 (вместе с autovacuum/pg_dump и прочими некритичными к скорости IO вещами).
Но вообще использование ssd делает эту задачу малоактуальной.
3)вероятно не будет сделано никогда так как target_tanyelement не может иметь разные типы... pl/pgsql архитектурно не умеет работать с полиморфными переменными (и не будет уметь). Так что я бы на это не расчитывал. Да и hstore workaround не такой уж ужасный на практике.
