Re: Aggregates with non-commutative transition functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Emmanuel Charpentier <charpent(at)bacbuc(dot)dyndns(dot)org>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Aggregates with non-commutative transition functions
Date: 2003-02-15 15:42:07
Message-ID: 16193.1045323727@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Emmanuel Charpentier <charpent(at)bacbuc(dot)dyndns(dot)org> writes:
> Since the stability of the sort is an issue but for this quite specific
> case, one could envision a flag to "CREATE AGGREGATE", signalling the
> planner the fact that the transition function isn't commutative, hence the
> need to use a stable version of sort()

Actually, I would think that you'd really prefer that the system not
run a sort step at all.

As of CVS tip, if the planner decides to use hash-based aggregation
for your query then there wouldn't be any pre-sort. But there's no
guarantee it will do that.

A better alternative is to get the planner to notice in the context of
the outer query that the inner query's result is already sorted by
recnum. Then it wouldn't do the unwanted sort in any case. This has
been on the to-do list for awhile, but hasn't risen to the top ...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-02-15 15:49:20 Re: In 7.3.1, will I be able to reindex toast?
Previous Message frag 2003-02-15 15:24:15 Re: Restore from 7.3 to 7.2