Bernd Helmle <mailings@oopsware.de> writes:
> While looking into a customer performance problem, i saw this in
> costsize.c, cost_index() (9.3.6, but it looks the same in HEAD):
> ...
> What i'm wondering is the else branch, where the baserel row estimate is
> assigned to the
> IndexPath. However, it occurs to me that in conjunction with a partial
> index, the overall row estimate will be constrained by the row estimate
> from the partial index itself, no?
No. The non-parameterized paths for a given relation must all have the
same rowcount estimates; otherwise the path comparison logic fails
fundamentally. Another way to look at it is that every correct path
will yield the same number of rows in reality; so it would be wrong to
give a path that makes use of a partial index a rowcount advantage over
a path that is not using the partial index but nonetheless is enforcing
exactly the same set of scan restriction clauses.
What could potentially make sense is to detect applicability of partial or
unique indexes earlier than we do now, and use that knowledge to adjust
the relation's rows estimate overall, for all paths. But I'm not sure
how to do that without either (a) making the code a lot messier than it
is now or (b) duplicating a lot of work or (c) both.
regards, tom lane
