Re: policies with security definer option for allowing inline optimization - Mailing list pgsql-hackers

From Dan Lynch
Subject Re: policies with security definer option for allowing inline optimization
Date
Msg-id CA+_muLFDzuxZt8DwpzouM=BHe+TOn=YsS+WQ9m7VmxzZ_uYMUw@mail.gmail.com
Whole thread Raw
In response to Re: policies with security definer option for allowing inline optimization  (Noah Misch <noah@leadboat.com>)
Responses Re: policies with security definer option for allowing inline optimization  (Noah Misch <noah@leadboat.com>)
List 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 by date:

Previous
From: torikoshia
Date:
Subject: Re: Get memory contexts of an arbitrary backend process
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.