Re: policies with security definer option for allowing inline optimization
| От | Dan Lynch |
|---|---|
| Тема | Re: policies with security definer option for allowing inline optimization |
| Дата | |
| Msg-id | CA+_muLFDzuxZt8DwpzouM=BHe+TOn=YsS+WQ9m7VmxzZ_uYMUw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: policies with security definer option for allowing inline optimization (Noah Misch <noah@leadboat.com>) |
| Ответы |
Re: policies with security definer option for allowing inline optimization
|
| Список | pgsql-hackers |
This is great, thanks! It's great to have somewhere in the source to read about the optimizer! very cool!
> I suppose if the
> get_group_ids_of_current_user() function is marked as STABLE, would the
> optimizer cache this value for every row in a SELECT that returned
> multiple rows?
While there was a patch to implement caching, it never finished. The
optimizer is allowed to, and sometimes does, choose plan shapes that reduce
the number of function calls.
So for multiple rows, it's possible that the same query could happen for each row? Even if it's clearly stable and only a read operation is happening?
I suppose if the possibility exists that this could happen, perhaps using RLS for selects is not quite "production ready"? Or perhaps if the RLS qual/check is written well-enough, then maybe the performance hit wouldn't be noticed?
В списке pgsql-hackers по дате отправления: