Re: Performance issue when we use policies for Row Level Security along with functions
От | Tom Lane |
---|---|
Тема | Re: Performance issue when we use policies for Row Level Security along with functions |
Дата | |
Msg-id | 1502555.1600265853@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Performance issue when we use policies for Row Level Security along with functions ("Gopisetty, Ramesh" <rameshg2@illinois.edu>) |
Ответы |
Re: Performance issue when we use policies for Row Level Security along with functions
|
Список | pgsql-performance |
"Gopisetty, Ramesh" <rameshg2@illinois.edu> writes: > Policy > create policy policy_sel on test FOR SELECT to ram1 USING ( testkey in (f_sel_policy_test(testkey)) ); > Going to a Sequential scan instead of index scan. Hence, performance issue. > If i replace the policy with stright forward without function then it chooses the index. Not sure how i can implementwith the function. > create policy policy_sel on test FOR SELECT to ram1 USING ( testkey in ('COMMON',current_setting('ctx_ng'||'.'||'ctx_key_fil'))); " testkey in ('COMMON',current_setting('ctx_ng'||'.'||'ctx_key_fil')) " is an indexable condition on testkey, because it compares testkey to a constant (or at least, a value that's fixed for the life of the query). " testkey in (f_sel_policy_test(testkey)) " is not an indexable condition on anything, because there are variables on both sides of the condition. So there's no fixed value that the index can search on. If you intend f_sel_policy_test() to be equivalent to the other condition, why are you passing it an argument it doesn't need? As Luis noted, there's also the problem that an indexable condition can't be volatile. I gather that SYS_CONTEXT ends up being a probe of some GUC setting, which means that marking the function IMMUTABLE would be a lie, but you ought to be able to mark it STABLE. regards, tom lane
В списке pgsql-performance по дате отправления: