Re: prepared statements suboptimal?

rihad  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