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

From: Jonathan Bartlett <johnnyb(at)eskimo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dann Corbit <DCorbit(at)connx(dot)com>, <jim(at)nasby(dot)net>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: Index not being used in MAX function (7.2.3)
Date: 2003-06-11 17:44:22
Message-ID: Pine.GSU.4.44.0306111040550.25425-100000@eskimo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)connx(dot)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
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Network Administrator 2003-06-11 17:50:10 Re: [GENERAL] MySQL gets $19.5 MM
Previous Message Forest Wilkinson 2003-06-11 17:43:50 Re: [GENERAL] How to enumerate foreign key constraints after migrating from 7.1.3?