Re: Optimizer picks an ineffient plan

On 5 Sep 2003, Greg Stark wrote:

>
> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
>
> > On Wed, 3 Sep 2003, Bupp Phillips wrote:
> >
> > > Well, it's unfortunate that you feel that way, because SQL Server handles it
> > > correctly.
> >
> > For some definition of correctly. If you're in a system which gets
> > penalized .001 seconds for each query planning that uses a multi-column
> > order by and you do 100 million of them that this doesn't apply to, and
> > one that it does which save you 30 seconds, is that correct?
>
> Uhm. Yes. Absolutely.

Even if all the people that don't write queries with redundant sort
columns pay the cost for those that do? In some ways it'd be nice if we
could control the planner more so that individual systems could make
determinations of whether this was useful or not.

From the below, I'm not sure we're talking about the same case any longer.
:)

> I'm pretty sure this particular case was not one of the cases where people
> said it just wasn't worth doing. This was just too hard. Solving it in a way
> that integrates cleanly with postgres's aggregates will be very hard and
> require someone who understands lots of different parts of postgres to spend
> an awful lot of time thinking about the problem.

I'm not sure how finding redundant sort columns due to unique constraints
really integrates with aggregates at all. Did we maybe cross conversation
with one of the aggregate discussions on min/max/count?