Re: parameterized limit statements
От | Merlin Moncure |
---|---|
Тема | Re: parameterized limit statements |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3417DD7F4@Herge.rcsinc.local обсуждение исходный текст |
Ответ на | parameterized limit statements ("Merlin Moncure" <merlin.moncure@rcsonline.com>) |
Ответы |
Re: parameterized limit statements
|
Список | pgsql-hackers |
> "Merlin Moncure" <merlin.moncure@rcsonline.com> 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 use value in comparison right before it was assigned). I am still getting prepared statements that are flipping to seqscan or bitmap scan. The statements are invariably in form of select a,b,c,d from twhere 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? FYI: the planner gets it right about 95% of the time and produces the best possible plan...an index filtering on a and scanning for b,c,d. Merlin
В списке pgsql-hackers по дате отправления: