On Tue, Jul 8, 2014 at 7:57 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > On Mon, Jul 7, 2014 at 7:37 PM, Tom Lane wrote:
> >> 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
Ashutosh Bapat writes:
> On Mon, Jul 7, 2014 at 7:37 PM, Tom Lane wrote:
>> 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 pr
On Mon, Jul 7, 2014 at 11:46 PM, Greg Stark wrote:
> On Mon, Jul 7, 2014 at 3:07 PM, Tom Lane wrote:
> > 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
On Mon, Jul 7, 2014 at 7:37 PM, Tom Lane wrote:
> Ashutosh Bapat 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. v
On Mon, Jul 7, 2014 at 3:07 PM, Tom Lane wrote:
> 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.
W
Ashutosh Bapat 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 e
