Re: Index is not used for "IN (non-correlated subquery)"
От | George |
---|---|
Тема | Re: Index is not used for "IN (non-correlated subquery)" |
Дата | |
Msg-id | CAO=sJoUbTWxtmQvkBHVpE11fW9q9+cvosEb4_KvM=Yt=kfCBew@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Index is not used for "IN (non-correlated subquery)" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Index is not used for "IN (non-correlated subquery)"
|
Список | pgsql-general |
On Wed, Nov 30, 2016 at 8:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Merlin Moncure <mmoncure@gmail.com> writes: >> On Wed, Nov 30, 2016 at 11:05 AM, George <pinkisntwell@gmail.com> wrote: >>> So there is definitely something wrong here. This situation makes many >>> row-level security use cases cumbersome since you need to have >>> almost the same WHERE clause both in the row-level security policy and >>> in every SELECT query in order for the index to be used. > >> can you give EXPLAIN ANALYZE for the 'good' query and the 'bad' query? > > Planning for queries affected by RLS is definitely an area where we need > to improve (I'm working on a patch for that). Whether the OP's particular > query is being hit by that is impossible to tell, though, since there > isn't any actual RLS usage in the doubtless-oversimplified example. The example is not over-simplified, I basically just took the clause that the RLS would have to add and stuck it in the WHERE. Thus I verified that even the normal, non-RLS planner is affected. When I get to work tomorrow morning (Europe) I will post the EXPLAIN ANALYZE output.
В списке pgsql-general по дате отправления: