In investigating the planner changes necessary for the append node planning I
described in my other email I noticed something else I find strange.
The min/max optimization which builds an ORDER BY ... LIMIT 1 type of plan
for min or max works by explicitly building an index path to scan a plain
Gregory Stark [EMAIL PROTECTED] writes:
I don't understand why it wouldn't work to do it for any arbitrary path for
any query at all as long as it has the correct ordering.
It might work, but the resulting plan would be uniformly inferior to the
regular aggregate code. The only case where the
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
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
