| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Rod Taylor <pg(at)rbt(dot)ca>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Large Scale Aggregation (HashAgg Enhancement) |
| Date: | 2006-01-17 23:29:22 |
| Message-ID: | 1137540562.3180.302.camel@localhost.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2006-01-17 at 21:43 +0000, Simon Riggs wrote:
> OK.... My interest was in expanding the role of HashAgg, which as Rod
> says can be used to avoid the sort, so the overlap between those ideas
> was low anyway.
Am I right in thinking that HashAgg would almost always be quicker than
SortAgg, even for large (> memory) aggregation sets? (Except where the
prior ordering has already been forced via an ORDER BY).
If that is so, then I will probably look to work on this sooner,
especially since we seem to have a clear design.
I'd originally viewed the spill-to-disk logic as a safety measure rather
than as a performance feature.
Best Regards, Simon Riggs
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neil Conway | 2006-01-18 00:17:09 | debug_query_string and multiple statements |
| Previous Message | Simon Riggs | 2006-01-17 21:43:09 | Re: Large Scale Aggregation (HashAgg Enhancement) |