Hi, I don't know whether this input would be useful. But what i could observe from the behavior of MIN/MAX is
It goes to the proper page, but starts the page scan in a opposite way. Say for example you want the min value, it goes to the first leaf page, but starts from the last tuple and comes to the top. For Max, it goes to the last page and starts scanning from top and reaches the bottom. If some extra information can be passed on to the scan, saying whether it is a min/max oper, then we can tune this part. I don't know how much we will save from this in-memory operation. But it would definitely do lesser work. Thanks, Gokul. On 10/27/07, Gregory Stark <[EMAIL PROTECTED]> wrote: > > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > The only case where the optimization is a win is where you have a > > zero-startup-cost subplan, and the only way to get sorted output with > zero > > startup cost is an indexscan. > > Sure but there could be other nodes above the index scan which preserve > the > order. In particular nested loop and merge joins. Unique also preserves > the > order but I can't see how it could be useful here. And of course > potentially > Append nodes in the future... > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- Thanks, Gokul. CertoSQL Project, Allied Solution Groups. (www.alliedgroups.com)
