Re: group by points

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Albe Laurenz <all(at)adv(dot)magwien(dot)gv(dot)at>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: group by points
Date: 2006-05-22 23:57:42
Message-ID: 20060522235742.GA4051@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 22, 2006 at 18:38:35 -0400,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> > On Mon, May 22, 2006 at 10:23:28 +0200,
> > Albe Laurenz <all(at)adv(dot)magwien(dot)gv(dot)at> wrote:
> >> In order to (efficiently) process a GROUP BY clause, you need a
> >> total ordering on the data type that you group by, i.e. an ordering
> >> such that for any two data x and y you have either x < y or x > x
> >> or x = y.
>
> > An equality operator is good enough if the number of unique groups isn't too
> > large, so that a hash aggregate plan works efficiently.
>
> Doesn't help for the case at hand, since point_eq isn't marked hashable
> either. It would be good to fix things so that the system doesn't
> insist on having the sorting option available, though.

Yeah, I thought about that later on my way home. You need to have a hash
function that maps equal values to the same hash bucket or things don't
work.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-05-23 01:25:42 Re: [HACKERS] Duplicate definition of LOCALEDIR
Previous Message Tom Lane 2006-05-22 23:47:46 Re: Porting MSSQL to PGSQL (Was: [OT] MySQL is bad, but THIS bad?)