Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I do notice that createplan.c makes some effort to get rid of filter
>> conditions that are provably true when the index conditions are.
>> Doesn't look like it considers the reverse direction. Not sure if
>> that's missing a bet.
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > We have already figured out that the user's predicate results in a
> > subset of the index's or we wouldn't be able to use that index though,
> > right? Do we really need to spend cycles re-discovering that? Are
> > there c
Stephen Frost writes:
> We have already figured out that the user's predicate results in a
> subset of the index's or we wouldn't be able to use that index though,
> right? Do we really need to spend cycles re-discovering that? Are
> there cases where we actually need the index's predicate to ev
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Perhaps I'm missing something obvious, but isn't it a bit redundant to
> > have both a Recheck condition (which is the predicate of the index) and
> > a Filter condition (which is the user's predicate) when we've already
> >
Stephen Frost writes:
> Perhaps I'm missing something obvious, but isn't it a bit redundant to
> have both a Recheck condition (which is the predicate of the index) and
> a Filter condition (which is the user's predicate) when we've already
> decided that the user's predicate must result in a subs
Greetings,
Consider this:
create table t10 (c1 int, c2 int);
create index on t10 (c1) where c2 > 5;
\d t10
Table "sfrost.t10"
Column | Type | Modifiers
+-+---
c1 | integer |
c2 | integer |
Indexes:
"t10_c1_idx" btree (c1) WHERE c2 > 5
insert in