From: | Mark Kirkwood <markir(at)coretech(dot)co(dot)nz> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MAX/MIN optimization via rewrite (plus query rewrites |
Date: | 2004-11-11 07:55:23 |
Message-ID: | 41931AEB.8010807@coretech.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
There seems to be (as Tom indicated) a choice of approaches:
i) rewrite max/min querys and then plan 'em
ii) provide alternate plans based on presence of certain aggregate types
in the query
when I first examined this TODO item, I was really thinking about i),
but I suspect that ii) is probably the best approach.
regards
Mark
Bruno Wolff III wrote:
>On Thu, Nov 11, 2004 at 17:57:42 +1300,
> Mark Kirkwood <markir(at)coretech(dot)co(dot)nz> wrote:
>
>
>>Your example and ones like :
>>
>>SELECT max(foo), count(foo) FROM bar
>>SELECT max(a.foo1), max(b.foo2) FROM bar1 AS a NATURAL JOIN bar2 AS b
>>
>>have made me realize that the scope of "what should be optimized" is
>>somewhat subtle.
>>
>>I am inclined to keep it simple (i.e rather limited) for a first cut,
>>and if that works well, then look at extending to more complex rewrites.
>>
>>What do you think?
>>
>>
>
>I don't think you should be rewriting queries as much as providing
>alternate plans and letting the rest of the optimizer decided which
>plan to use. If you just rewrite a query you might lock yourself into
>using a poor plan.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2004-11-11 08:01:46 | Re: MAX/MIN optimization via rewrite (plus query rewrites |
Previous Message | Jim C. Nasby | 2004-11-11 07:18:05 | Re: MAX/MIN optimization via rewrite (plus query rewrites |