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 <stark@enterprisedb.com> wrote: "Tom Lane" <tgl@sss.pgh.pa.us> 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 )
