On Mon, Nov 6, 2017 at 5:19 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > 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.
I don't think that's a good justification for allowing the order to vary. It's true that, at execution time, we may find row counts and selectivities to be different than what we predicted, but that is a case of the real data being different from our idealized data -- which is difficult to avoid in general. Allowing our actual decisions to be different from the decisions we thought we would make seems like programmer sloppiness. It would also be very confusing if the planner uses one ordering to estimate the cost and then a different order at execution time and in the EXPLAIN ANALYZE output. How could anybody understand what had happened in such a case? I think it would be a good idea, as Thomas says, to order the qual clauses at an earlier stage and then remember our decision. However, we have to think about whether that's going to increase planning time in a noticeable way. I wonder why we currently postpone this until such a late phase of planning. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers