From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at> |
Cc: | "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 15:24:34 |
Message-ID: | 8198.1100186674@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at> writes:
>> How are you planning to represent the association between MIN/MAX and
>> particular index orderings in the system catalogs?
> Don't we already have that info to decide whether an index handles
> an "ORDER BY" without a sort node ?
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2004-11-11 15:59:08 | Re: Vacuum info clarification |
Previous Message | Robert Treat | 2004-11-11 15:20:43 | Re: Increasing the length of |