Bernd Helmle <maili...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers