On Mon, Nov 6, 2017 at 10:01 AM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > > This idea seems to makes intuitive sense. I see that you use > order_qual_clauses() to know what order they'll run in, so I'm > wondering if there is any reason we shouldn't do it up front and keep > it during path building, instead of running it again at plan creation > time. Is there some way it could ever produce a different result at > the two times?
IIRC, only thing that changes between plan time quals and execution time quals is constaint folding of constant parameters. But I don't think we change the selectivity estimates when that's done. At the same time, I don't think we should make a lot of effort to make sure that the order used during the estimation is same as the order at the execution; we are anyway estimating. There can always be some difference between what's estimated and what actually happens. > Why not also apply this logic to qpquals of joins, > foreign scans, subplans? That is, instead of replacing cost_qual_eval > with this code for baserels, I wonder if we should teach > cost_qual_eval how to do this so those other users could also benefit > (having perhaps already ordered the qual clauses earlier). +1. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
