Martijn van Oosterhout <kleptog@svana.org> writes:
> OK, so how to fix this. It seems to me that all that is required is that for
> partial indicies it should try to add a path for a plain index scan over the
> index and let the cost estimator decide if it's cheaper than a sequential
> scan.
Probably a reasonable first cut: if the index predicate fits, then always
generate a path. This assumes that partial indexes are usually made to
cover relatively small fractions of the table, but I'm willing to
believe that for starters.
> only thing is, will the cost estimator get it right. At least the partial
> index has an accurate count of the number of matching rows.
Why would you think that?
I can pretty much guarantee that the cost estimator will *not* get it
right --- it has no idea about partial indexes. You'll need to do some
fooling with the index selectivity estimation routines to account for
the effects of the predicate.
regards, tom lane
