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
On 2020-Sep-14, David Rowley wrote:
> On Tue, 8 Sep 2020 at 06:05, Raj wrote:
> >
> > > This would not exactly look like a bug, because the message says "to
> > > be locked", so at least it's not allowing two workers to lock the same
> > > tuple. But it seems that the skip-locked mode should not
On Tue, 8 Sep 2020 at 06:05, Raj wrote:
>
> > This would not exactly look like a bug, because the message says "to
> > be locked", so at least it's not allowing two workers to lock the same
> > tuple. But it seems that the skip-locked mode should not make an error
> > out of this, but treat it as
