On Thu, May 31, 2012 at 3:52 PM, Kohei KaiGai <kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
