| From: | Michael Lewis <mlewis(at)entrata(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "Gopisetty, Ramesh" <rameshg2(at)illinois(dot)edu>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Performance Issue (Not using Index when joining two tables). |
| Date: | 2020-09-14 02:51:00 |
| Message-ID: | CAHOFxGqVg9S3dZS4GHzqefc36FschzDVLsOG_jRgm4MwjfDxVw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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 limited, but perhaps those restrictions are influencing the planners
access or reliance on stats.
Also, it would seem like you need the entire table since you don't have an
explicit where clause. Why would scanning an index and then also visiting
every row in the table be faster than just going directly to the table?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gopisetty, Ramesh | 2020-09-14 03:18:26 | Re: Performance Issue (Not using Index when joining two tables). |
| Previous Message | Tom Lane | 2020-09-13 17:07:07 | Re: Performance Issue (Not using Index when joining two tables). |