Re: Hash grouping, aggregates

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.

In response to

Responses

Browse pgsql-hackers by date

  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: