Re: DONT_CARE Aggregate

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: Robert James <srobertjames(at)gmail(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: DONT_CARE Aggregate
Date: 2012-12-20 17:36:47
Message-ID: 14421.1356025007@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Marti Raudsepp <marti(at)juffo(dot)org> writes:
> On Thu, Dec 20, 2012 at 3:28 AM, Robert James <srobertjames(at)gmail(dot)com> wrote:
>> Is there an aggregate that will return an arbitrary instance? That is,
>> not necessarily the max or min, just any one? (Which might perform
>> better than max or min)
>>
>> More importantly:
>> Is there one which will return an arbitrary instance as long as it's not NULL

> There's an extension on PGXN which implements first()/last()
> aggregates in C: http://pgxn.org/dist/first_last_agg/

> It should be slightly faster than min()/max(), but the difference is
> probably not significant in more complex queries.

Another thing to consider is that the presence of any "generic"
aggregate forces a full-table scan, since the system doesn't know that
the aggregate has any particular behavior. MIN/MAX on the other hand
can be optimized into index probes, if they are on indexed columns.
If the query otherwise uses only MIN/MAX aggregates, it's not hard
to believe that adding a FIRST() or LAST() instead of a MIN/MAX
aggregate could make the query significantly slower, not faster.

However, if you're targeting queries containing a variety of aggregates,
or if any of them are on unindexed columns, then this special case may
not be of much interest.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2012-12-20 18:20:05 Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1
Previous Message Marti Raudsepp 2012-12-20 17:24:35 Re: DONT_CARE Aggregate