rihad <rihad@xxxxxxx> writes: > Aha, thanks for a thorough explanation. Now I understand that while > looking for a way to fulfill the query postgres will try hard to pick > the one requiring the least number of rows visits. I've skimmed over my > queries: almost all of them make use of the primary key as the first > thing in the WHERE clause (say, a username, which is the only pk in the > table): shouldn't that be enough for postgres to *always* decide to scan > the pk's index (since a query on a pk always returns either one or zero > results)? Yeah, if there's always a PK equality constraint then the dependence on specific parameter values is much weaker, so you could probably use a prepared statement without worrying. The cases where prepared statements tend to suck usually involve either inequalities, or equalities on non-unique columns where the number of matches varies wildly for different data values. In cases like that, knowing the exact value being compared to makes a very large difference in the rowcount estimate. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
