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) as it is,
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 know how to
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 would you
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
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) is
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
function
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 on
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
has to be
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
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
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() is only
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
which is
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 (select x,a,b from table
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
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
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 that
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
would
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 in such
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
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
20 matches
Mail list logo
