From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parameterized limit statements |
Date: | 2005-11-07 17:37:17 |
Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB3417DD7F4@Herge.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)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 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?
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-11-07 17:43:36 | Re: parameterized limit statements |
Previous Message | Tom Lane | 2005-11-07 17:07:27 | Re: Interval aggregate regression failure (expected seems |