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.
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?) |