From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Zeugswetter Andreas DAZ SD <ZeugswetterA(at)spardat(dot)at>, Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
Date: | 2004-11-11 18:03:20 |
Message-ID: | 20041111180320.GD25936@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 11, 2004 at 10:24:34 -0500,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> We know how to determine that an index matches an ORDER BY clause.
> But what has an aggregate called MAX() got to do with ORDER BY? Magic
> assumptions about operators named "<" are not acceptable answers; there
> has to be a traceable connection in the catalogs.
>
> As a real-world example of why I won't hold still for hard-wiring this:
> a complex-number data type might have btree opclasses allowing it to be
> sorted either by real part or by absolute value. One might then define
> max_real() and max_abs() aggregates on the type. It should be possible
> to optimize such aggregates the same way as any other max() aggregate.
Wouldn't knowing an opclass and direction associated with an aggregrate
function allow you to do this?
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2004-11-11 18:15:09 | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
Previous Message | Bruno Wolff III | 2004-11-11 17:59:06 | Re: MAX/MIN optimization via rewrite (plus query |