On Oct 27, Karl Czajkowski modulated:
> Hi, I am struggling to find information on how the new parallel query
> features intersect with row-level security. I am wondering whether
> this is expected to work at this time?
>
Further experimentation shows that I can get parallel plans with
row-level security, if I remove our ugly policy with a scalar subquery
and instead denormalize the decision into another column of the same
table (i.e. one managed by a trigger).
However, our policies are still adding huge overhead. If I lie and
say our stored procedure is IMMUTABLE rather than STABLE, the
optimizer lifts our first (row-independent) policy check out of the
per-row filter and the query is 10x faster. But it seems to execute it
per-row when it is marked as STABLE, even though the function takes no
arguments and so does not vary by row.
But, our procedure calls current_setting which has STABLE volatility.
Does the session/connection cache plans? Would declaring our function
as IMMUTABLE accidentally allow reuse of (stale) plans across
boundaries where we have modified the session parameter? My
conservative reading of the docs suggests it might, which would make
this cheat unsafe for us...
Thanks,
Karl
