Re: [PATCH] Lazy hashaggregate when no aggregation is needed - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Lazy hashaggregate when no aggregation is needed
Date
Msg-id 22709.1332944158@sss.pgh.pa.us
Whole thread Raw
In response to [PATCH] Lazy hashaggregate when no aggregation is needed  (Ants Aasma <ants@cybertec.at>)
Responses Re: [PATCH] Lazy hashaggregate when no aggregation is needed  (Jay Levitt <jay.levitt@gmail.com>)
List pgsql-hackers
Ants Aasma <ants@cybertec.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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Next
From: Tom Lane
Date:
Subject: Re: 9.2 commitfest closure (was Command Triggers, v16)