On Thu, Nov 11, 2004 at 08:00:01AM -0600, Bruno Wolff III wrote:
> On Thu, Nov 11, 2004 at 17:52:19 +1100,
> John Hansen <[EMAIL PROTECTED]> wrote:
> > Why not just change the function all together to 'select $1 from $2
> > order by $1 desc limit 1;'
> >
> > Is there ANY situation where max(col)
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> Oh? How is a first() aggregate going to know what sort order you want
> >> within the group?
>
> > It would look something like
>
> > select x,first(a),first(b) from (sel
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Oh? How is a first() aggregate going to know what sort order you want
>> within the group?
> It would look something like
> select x,first(a),first(b) from (select x,a,b from table order by x,y) group
> by x
> whi
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > It would also make it possible to deprecate DISTINCT ON in favour of GROUP
> > BY
> > with first() calls.
>
> Oh? How is a first() aggregate going to know what sort order you want
> within the group? AFAICS first
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Re: knowing internal representation, I think this is required anyway;
> else the optimization would only work on a very limited numer of
> situations.
The point of my remark is that pushing this knowledge out to a function
is helpful only if you can put
Greg Stark <[EMAIL PROTECTED]> writes:
> It would also make it possible to deprecate DISTINCT ON in favour of GROUP BY
> with first() calls.
Oh? How is a first() aggregate going to know what sort order you want
within the group? AFAICS first() is only useful when you honestly do
not care which g
On Thu, Nov 11, 2004 at 10:24:34 -0500,
Tom Lane <[EMAIL PROTECTED]> 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
>
Tom Lane <[EMAIL PROTECTED]> writes:
> 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
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> 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?
> Wouldn't knowing an opclass and direction associated with an aggregrate
> f
On Thu, Nov 11, 2004 at 17:52:19 +1100,
John Hansen <[EMAIL PROTECTED]> wrote:
> Why not just change the function all together to 'select $1 from $2
> order by $1 desc limit 1;'
>
> Is there ANY situation where max(col) as it is, would be faster?
Yes. A couple I can think of are:
When count(col
> 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 ?
Andreas
---(end of broadcast)-
On Thu, Nov 11, 2004 at 01:08:39AM -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > What about having a new column in pg_aggregate which would point to a
> > function that would try to optimize the aggregate's handling?
>
> I can't get very excited about this, because how wo
"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> 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 kn
Why not just change the function all together to 'select $1 from $2
order by $1 desc limit 1;'
Is there ANY situation where max(col) as it is, would be faster?
... John
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What about having a new column in pg_aggregate which would point to a
> function that would try to optimize the aggregate's handling?
I can't get very excited about this, because how would you make a
reasonably stable/narrow API for such a thing? The f
On Thu, Nov 11, 2004 at 11:48:49AM +1300, Mark Kirkwood wrote:
> I am looking at implementing this TODO item. e.g. (max case):
>
> rewrite
> SELECT max(foo) FROM bar
> as
> SELECT foo FROM bar ORDER BY foo DESC LIMIT 1
> if there is an index on bar(foo)
Out of curiosity, will you be doing this i
On Wed, Nov 10, 2004 at 22:21:31 -0300,
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 10, 2004 at 07:18:59PM -0500, Tom Lane wrote:
>
> > A more radical way of handling it would be to detect the relevance of an
> > indexscan in indxpath.c and generate a special kind of Path node; this
On Wed, Nov 10, 2004 at 07:18:59PM -0500, Tom Lane wrote:
> A more radical way of handling it would be to detect the relevance of an
> indexscan in indxpath.c and generate a special kind of Path node; this
> would not generalize to other sorts of things as you were hoping, but
> I'm unconvinced th
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> I am looking at implementing this TODO item. e.g. (max case):
> My initial thoughts revolved around extending the existing RULE system
> to be able to handle more general types of rewrite - like conditionals
> in SELECT rules and rewrites that change e
I am looking at implementing this TODO item. e.g. (max case):
rewrite
SELECT max(foo) FROM bar
as
SELECT foo FROM bar ORDER BY foo DESC LIMIT 1
if there is an index on bar(foo)
Suggestions about the most suitable point in the parser/planner stage to
perform this sort of rewrite would be most welco
20 matches
Mail list logo
