RE: [pgsql-ru-general] Зацените типчик
От | Ilia Kantor |
---|---|
Тема | RE: [pgsql-ru-general] Зацените типчик |
Дата | |
Msg-id | auto-000454229111@backend2.aha.ru обсуждение исходный текст |
Ответы |
Re: Зацените т
("Andrey N. Oktyabrski" <ano@antora.ru>)
|
Список | pgsql-ru-general |
> -----Original Message----- > From: Andrey N. Oktyabrski [mailto:ano@antora.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. Ответ был преднамеренно не в рассылку, или туда предназначался? В > рассылку дублировать это письмо? Дублируй плиз свое письмо. Мое я продублировал только что.
В списке pgsql-ru-general по дате отправления: