Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes: > Right now, constraint exclusion code looks only at the provided conditions. > If we want avoid table scan based on constraints in the above example, it > will need to look at the implied conditions as well. E.g. val2 < 30 AND val > = val2 => val < 30. Then the constraint exclusion can see that val < 30 AND > val > 30 are contradictory and infer that the result is going to be empty. > We will need to add information about the transitive inferences between > operators. Can we do that in PostgreSQL? Will the benefits be worth the > code, that needs to be added?
I doubt it. The extra code isn't the problem so much, it's the extra planning cycles spent trying to make proofs that will usually fail. What you propose will create a combinatorial explosion in the number of proof paths to be considered. > I can see some more benefits. We can use it to eliminate joins where the > constraints on joining relations may cause the join to be empty e.g. ... and applying constraint exclusion to join relations would make that problem even worse. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers