Re: parameterized limit statements - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: parameterized limit statements
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3417DD7F4@Herge.rcsinc.local
Whole thread Raw
In response to parameterized limit statements  ("Merlin Moncure" <merlin.moncure@rcsonline.com>)
Responses Re: parameterized limit statements  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Interval aggregate regression failure (expected seems
Next
From: Tom Lane
Date:
Subject: Re: parameterized limit statements