Re: [PATCH] Lazy hashaggregate when no aggregation is needed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ants Aasma <ants(at)cybertec(dot)at>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Francois Deliege <fdeliege(at)gmail(dot)com>
Subject: Re: [PATCH] Lazy hashaggregate when no aggregation is needed
Date: 2012-03-28 14:15:58
Message-ID: 22709.1332944158@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ants Aasma <ants(at)cybertec(dot)at> writes:
> A user complained on pgsql-performance that SELECT col FROM table
> GROUP BY col LIMIT 2; performs a full table scan. ISTM that it's safe
> to return tuples from hash-aggregate as they are found when no
> aggregate functions are in use. Attached is a first shot at that.

As I commented in the other thread, the user would be a lot better off
if he'd had an index on the column in question. I'm not sure it's worth
complicating the hashagg logic when an indexscan + groupagg would
address the case better.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-03-28 14:20:10 Re: 9.2 commitfest closure (was Command Triggers, v16)
Previous Message Peter Geoghegan 2012-03-28 14:12:31 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)