Re: Зацените т
От | Andrey N. Oktyabrski |
---|---|
Тема | Re: Зацените т |
Дата | |
Msg-id | 44AEB313.1080701@antora.ru обсуждение исходный текст |
Ответ на | RE: [pgsql-ru-general] Зацените типчик ("Ilia Kantor" <ilia@obnovlenie.ru>) |
Список | pgsql-ru-general |
Ilia Kantor wrote: >>> Когда-то я делал похожую вещь. >>> А именно - поле (или поля) проверки доступа. >>> >>> Поле состояло из массива int[], содержащего ID нужных групп доступа. >> Это довольно громоздко - массивы. Я именно хотел сделать так, чтобы >> девелОперы пользовались - читай чтоб выглядело более-менее привычно, и >> чтобы оверхед поменьше был. > Много групп - несколько прав, вложенные группы. > Как у тебя такое сделать? Я когда планировал, осознавал что ограничения есть и представлял себе как они выглядят :-) Простой пример: в freebsd есть UFS ACLs. Как часто этим пользуются? В подавляющем большинстве случаев достаточно традиционной системы разграничения доступа. Так и здесь. То, что не лезет в эту модель, будет просто реализовано другими средствами. Однако, не так уж и много ограничений. Несколько прав есть, вложенные группы есть. Нет только "много групп" - вместо них три (юзер, группа и все остальные). Причём, заменить в случае необходимости одного юзера на список юзеров и один row_acl на массив из них не так уж сложно. >>> Для того, чтобы оптимизер мог сделать правильный план, пришлось писать >>> собственную статистику по таким полям (т.е по int[]). >> У меня вроде оптимизёр пользуется индексом, проверял. Кстати, забыл там >> в README пример создания индекса показать: >> CREATE INDEX obj_acl_idx ON obj USING gist (acl gist_row_acl_ops); > Да, но тут небольшая проблема. Когда ты делаешь сложный SQL-запрос, то > оптимизатор должен подсчитать предполагаемое количество результатов каждого > джойна и каждой выборки (селективность). > > ГИСТ-индексы в простейшем случае создаются без функции, которая подсчитывает > селективность, с заглушкой - типа всегда 1% от таблицы. Что это за функция? Где можно взять пример? Как её подключить - есть штатные средства, или постгрес хачить? Если второе, скорее всего не возьмусь, ибо дело неблагодарное. > Если ты делаешь сложный запрос, а результатов на самом деле 90%, то > оптимизатор в отсутствии правильной функции и статистики, составит неверный > план. > > Хуже всего, когда (в моем случае) есть ряд групп, которые почти всевластны > (95% рядов удовлетворяют запросу) и ряд групп, которые обладают правом на > некоторые объекты (1% рядов или меньше). > > Скорее всего, и у тебя возможна такая ситуация, она довольно типична для > прав. Надо думать и пробовать моделировать. Если в это упрусь, думать ещё - как обойти техническую проблему административными средствами. > Тогда оптимизатор создает неверный план для всевластных групп (думает что > 1%, а там все 99%) и, например, использует Nested Loop в неправильную > сторону (думает что 20 рядов, а там 20000). Результат плачевный, запросы > просто писать нельзя. Да, звучит логично и печально :-( Но построчное разделение прав всё-таки нужно, а в обозримом будущем обещают только постолбцовое (которое, кстати, и мне сильно поможет запретить чтение чего не положено из таблицы). Так что деваться некуда - либо что-то придумывать, либо менять инструменты. Перед тем как сделать второе, надо доказать что первое невозможно :-) >>> Однако, как внедрить ее в VACUUM/ANALYZE - неясно, а разработчикам на >>> сие накакать, видимо (никто не помог). Может, просто не было предусмотрено такое в постгресе?
В списке pgsql-ru-general по дате отправления: