Re: [RFC] Interface of Row Level Security
От | Robert Haas |
---|---|
Тема | Re: [RFC] Interface of Row Level Security |
Дата | |
Msg-id | CA+TgmoYDKHb_C4M_Uze5jTxXAcw3VqNadwS+A1D4G0zHw5KbhA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [RFC] Interface of Row Level Security (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: [RFC] Interface of Row Level Security
|
Список | pgsql-hackers |
On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: > It may be an option to separate the case into two; a situation to execute > the given query immediately just after optimization and never reused, > and others. Yes. Simon suggested exactly this a while back, and I agree with him that we ought to have it. > Even though the second situation, it may give us better query execution > plan, if we try to reconstruct query plan just before executor with > assumption that expects immutable / stable function can be replaced > by constant value prior to execution. > In other words, this idea tries to query optimization again on EXECUTE > statement against to its nature, to replace immutable / stable functions > by constant value, and to generate wiser execute plan. > At least, it may make sense to have a flag on prepared statement to > indicate whether it has possible better plan with this re-construction. This sounds complex and inefficient to me. > Then, if so, we will be able to push the stuff corresponding to > RLSBYPASS into the query optimization, and works transparently > for users. You're still going to need a way to make sure that the cluster can be dumped properly. RLSBYPASS accomplishes that; your scheme doesn't. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: