Re: min/max planner optimization

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(at)enterprisedb(dot)com> wrote:
>
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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)