From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | rihad <rihad(at)mail(dot)ru> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: prepared statements suboptimal? |
Date: | 2007-11-07 17:10:23 |
Message-ID: | 18415.1194455423@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
rihad <rihad(at)mail(dot)ru> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Collin Kidder | 2007-11-07 17:12:11 | Re: Syntax error in a large COPY |
Previous Message | Nick Johnson | 2007-11-07 17:07:03 | strange timezone problem |