RE: [pgsql-ru-general] Зацените типчик

> -----Original Message-----
> From: Andrey N. Oktyabrski [mailto:ano(at)antora(dot)ru]
> Sent: Friday, July 07, 2006 4:53 PM
> To: Ilia Kantor
> Subject: Re: [pgsql-ru-general] Зацените типчик
>
> Ilia Kantor wrote:
> > Когда-то я делал похожую вещь.
> > А именно - поле (или поля) проверки доступа.
> >
> > Поле состояло из массива int[], содержащего ID нужных групп доступа.
> Это довольно громоздко - массивы. Я именно хотел сделать так, чтобы
> девелОперы пользовались - читай чтоб выглядело более-менее привычно, и
> чтобы оверхед поменьше был.
Много групп - несколько прав, вложенные группы.
Как у тебя такое сделать?

>
> > Проверка на доступ осуществлялась операцией @.
> > Брались все группы юзера и проверялось, пересекаются ли они с полем.
> >
> > Если да, то право имеет. Сам оператор пересечения @ работал через
> > GIST-индекс.
> > Все пахало достаточно быстро и красиво, благо групп не так много разных.
> >
> > Для того, чтобы оптимизер мог сделать правильный план, пришлось писать
> > собственную статистику по таким полям (т.е по 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 - неясно, а разработчикам на
> сие
> > накакать, видимо (никто не помог).
> >
> > Так и перешел на Оракл ;)
> Грустная история ;-)
Да, обидно. Ну да постгрес не забываю ;)

>
> P.S. Ответ был преднамеренно не в рассылку, или туда предназначался? В
> рассылку дублировать это письмо?
Дублируй плиз свое письмо. Мое я продублировал только что.