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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
