"Gopisetty, Ramesh" <rameshg2@xxxxxxxxxxxx> writes: > Thanks for looking into the problem/issue. Let me give more details about the functions... Yes, we are using row level 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
