Skip site navigation (1) Skip section navigation (2)

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

From: "Ilia Kantor" <ilia(at)obnovlenie(dot)ru>
To: "'Andrey N(dot) Oktyabrski'" <ano(at)antora(dot)ru>
Cc: <pgsql-ru-general(at)postgresql(dot)org>
Subject: RE: [pgsql-ru-general] Зацените типчик
Date: 2006-07-07 13:58:17
Message-ID: auto-000454229111@backend2.aha.ru (view raw or flat)
Thread:
Lists: 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. Ответ был преднамеренно не в рассылку, или туда предназначался? В
> рассылку дублировать это письмо?
Дублируй плиз свое письмо. Мое я продублировал только что.

Responses

pgsql-ru-general by date

Next:From: Andrey N. OktyabrskiDate: 2006-07-07 14:30:26
Subject: Re: Зацените т
Previous:From: Ilia KantorDate: 2006-07-07 13:47:11
Subject: RE: [pgsql-ru-general] Зацените типчик

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group