"Gopisetty, Ramesh" 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 interm
the
lengthy email and i'm trying to explain my best on this.
Thank you.
Regards,
Ramesh G
From: Michael Lewis
Sent: Sunday, September 13, 2020 10:51 PM
To: Tom Lane
Cc: Tomas Vondra ; Gopisetty, Ramesh
; pgsql-performance@lists.postgresql.org
Subje
Filter: ((("current_user"())::text <> ANY ('{wfnadmin,skipvpd}'::text[]))
AND f_sel_policy_all(vpd_key, 'CH
R_EMP_POSITION'::character varying) AND
f_sel_policy_prod_locale((cep.*)::character
varying, prod_locale_code))
This looks like some stuff for row level security perhaps. My understanding
is
Tomas Vondra writes:
> Most of the time (3460ms) is spent in the sequential scan on
> chr_simple_val, and the seqscan on chr_emp_position is taking ~330ms).
> Combined that's 3790ms out of 3797ms, so the join is pretty much
> irrelevant.
> Either the seqscans are causing a lot of I/O, or maybe th
On Sun, Sep 13, 2020 at 02:58:15PM +, Gopisetty, Ramesh wrote:
Hi,
Good Morning!
Postgres Version : 11.6 (AWS Native Postgres/AWS Aurora tried on both
flavours).
When i'm joining two tables the primary index is not being used. While is use
in clause with values then the index is bei
Hi,
Good Morning!
Postgres Version : 11.6 (AWS Native Postgres/AWS Aurora tried on both
flavours).
When i'm joining two tables the primary index is not being used. While is use
in clause with values then the index is being used. I have reindexed all the
tables, run the auto vaccum as w
