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: | Raw Message | Whole Thread | 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: |