"Gopisetty, Ramesh" <rameshg2@illinois.edu> writes:
> Thanks for looking into the problem/issue. Let me give more details about the functions... Yes, we are using
rowlevel security.
Hm. If those expensive filter functions are being injected by RLS on the
target tables (rather than by something like an intermediate view), then
the planner is constrained to ensure that they execute before any query
conditions that it doesn't know to be "leakproof". So unless your join
operator is leakproof, the shape of plan that you're hoping for will not
be allowed. Since you haven't mentioned anything about data types, it's
hard to know whether that's the issue. (The hash condition seems to be
texteq, which is leakproof, but there are also casts involved which
might not be.)
The two queries you provided explain plans for are not the same, so
comparing their plans is a fairly pointless activity. *Of course*
the query runs faster when you restrict it to fetch fewer rows. The
original query has no restriction clause that corresponds to the
clauses being used for index conditions in the second query, so it's
hardly a surprise that you do not get that plan, RLS or no RLS.
regards, tom lane
