Re: Index not being used in MAX function (7.2.3)

I wonder if a macro system might be warranted - then have max be a macro
instead of an aggregate.  However, I don't know exactly how that would
work since it involves the whole statement.  Anyway, just an idea to
hopefully spur someone else's thinking cap :)

Jon

On Wed, 11 Jun 2003, Tom Lane wrote:

> "Dann Corbit" <DCorbit@connx.com> writes:
> > Is this a poorly designed hack:
> >     Select max(expression) from <join> where <filter>
>
> Well, to start with, any nonempty WHERE probably invalidates the
> optimization, and I doubt it works if there's a join rather than a
> single table involved.  But you're just handwaving --- the devil is in
> the details.  How will you identify which aggregates are MIN and MAX
> (no, I don't like the idea of relying on the names; remember we have
> an extensible set of aggregates)?  What will you do when there are
> multiple aggregates in the command --- or more generally, how complex a
> context for the aggregate call are you going to be able to support?
> Where exactly is this transformation going to occur in the planning
> pipeline, and how many cycles will we waste checking for the possible
> transform in cases where it doesn't apply?  Questions like these are
> where we've gotten bogged down in the past.  You might care to consult
> the pgsql-hackers archives for past discussions.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>