"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> The statements are invariably in form of
> select a,b,c,d from t
> where a >= $1 and
> (a > $1 or b >= $2) and
> (a > $1 or b > $2 or c >= $3) and
> (a > $1 or b > $2 or c > $3 or d > $4)
> order by a, b, c, d limit $5;
> ^^
> If I hardcode $5 to any sub-ridiculous value, I get a proper index plan.
> Does your patch assume a limit of 1 or 10% of table rows?
If it doesn't have a value for the parameter, it'll assume 10% of table
rows, which is what it's done for a long time if the LIMIT isn't
reducible to a constant.
I suspect the real issue here is that whatever you are doing doesn't
give the planner a value to use for the parameter. IIRC, at the moment
the only way that that happens is if you use the unnamed-statement
variation of the Parse/Bind/Execute protocol.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
