"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...
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2007-10-27 15:04:19|
|Subject: Re: Datum should be defined outside postgres.h |
|Previous:||From: Pavel Stehule||Date: 2007-10-27 14:45:47|
|Subject: Re: Proposal: real procedures again (8.4)|