On Tue, Sep 26, 2017 at 11:32 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > There is a facility in the planner to require a condition for the first > column of an index before considering an indexscan plan. We could perhaps > extend that to require a condition for each column of the index, though > I'm not sure how much work is involved directly in that. The bigger > picture here though is that it puts a premium on *not* throwing away > "unnecessary" qual conditions, which is directly antithetical to a bunch > of other planner goals. > > User: Why won't the planner use my multicolumn hash index? > I have query conditions constraining all the columns! > Us: Well, one of your conditions was discarded because it was > constant-true after constant simplification, or redundant with > a partition qual or CHECK constraint, or implied by an index > predicate, or treated as a join condition instead of a > restriction condition, or absorbed into an equivalence class > and then the planner chose to emit some other equivalence > condition instead, or possibly two or three other things. > User: WAAAAH!
Ah. Yeah, that's a problem. -- 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
