rihad <[EMAIL PROTECTED]> 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
