On Mon, 2005-11-07 at 18:43, Tom Lane wrote:
[snip]
> 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.
Is 10% a reasonable guess here ?
Here we use limit in combination with prepar
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> hm...I'm using named statements over ExecPrepared. I can also confirm
> the results inside psql with prepare/execute. I can send you a test
> case, but was just wondering if your change to makelimit was supposed to
> address this case.
Nope, sorry.
"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)
> > ^^
> > 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 t
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > Is this correct?
>
> Sure, what do you think is wrong with it? plan_rows is initially a
copy
> of the child node's output-rows estimate, and then it gets modified.
OK, just a stab in the dark...not familiar at all with this code (seemed
odd to
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Is this correct?
Sure, what do you think is wrong with it? plan_rows is initially a copy
of the child node's output-rows estimate, and then it gets modified.
regards, tom lane
---(end of broadcast)---
I noticed your 8/18 commit to address an issue I raised regarding
parameterized limit statements. Specifically, prepared statements with
a variable limit would tend to revert to bitmap or seqscan.
I check out cvs tip and am still getting that behavior :(. So, I had a
look at createplan.c to see
