Skip site navigation (1) Skip section navigation (2)

Re: min/max planner optimization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: min/max planner optimization
Date: 2007-10-27 13:46:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Gregory Stark <stark(at)enterprisedb(dot)com> 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 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.  Anything
involving a sort will be a loser, or at best break-even if the sort
figures out it can use top-N.

> I would have expected the way to do this would be to detect that the min/max
> optimization might be applicable early on, in which case we teach
> pathkeys_useful_for_ordering about the ordering which would be necessary for
> it.

Possibly.  I did it the way I did mostly to minimize the side-effects on
the rest of the planner.  But I think if we did it like that, we'd waste
cycles considering ordered-output paths that are really not of any value
in light of the comments above.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-10-27 13:55:44
Subject: Re: Append nodes and orderings
Previous:From: Tom LaneDate: 2007-10-27 13:36:10
Subject: Re: Proposal: real procedures again (8.4)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group