| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Hash grouping, aggregates |
| Date: | 2003-02-11 16:44:04 |
| Message-ID: | 20030211164404.GA32571@wolff.to |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 11, 2003 at 10:41:53 -0500,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > So one of the items on the TODO list is "Add hash for evaluating GROUP BY
> > aggregates (Tom)"
>
> It's done in CVS tip ... give it a try.
>
> > The neat thing is that hash aggregates would allow grouping on data types that
> > have = operators but no useful < operator.
>
> Hm. Right now I think that would barf on you, because the parser wants
> to find the '<' operator to label the grouping column with, even if the
> planner later decides not to use it. It'd take some redesign of the
> query data structure (specifically SortClause/GroupClause) to avoid that.
I think another issue is that for some = operators you still might not
be able to use a hash. I would expect the discussion for hash joins in
http://developer.postgresql.org/docs/postgres/xoper-optimization.html
would to hash aggregates as well.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Patrick Welche | 2003-02-11 16:44:34 | Re: Changing the default configuration (was Re: [HACKERS] PostgreSQL Benchmarks) |
| Previous Message | Greg Copeland | 2003-02-11 16:42:54 | Re: Changing the default configuration (was Re: |