From: | ocie(at)paracel(dot)com |
---|---|
To: | darrenk(at)insightdist(dot)com (Darren King) |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] No: implied sort with group by |
Date: | 1998-01-28 18:42:54 |
Message-ID: | 9801281842.AA14281@dolomite.paracel.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Darren King wrote:
>
[examples deleted]
> I see two ways to fix the above, one w/minimal code, second w/more work, but
> potentially better speed for large queries.
>
> 1. Put a sort node immediately before the group node, taking into account
> any user given ordering. Also make sure the optimizer is aware of this sort
> when calculating query costs.
>
> 2. Instead of sorting the tuples before grouping, add a hashing system to
> the group node so that the pre-sorting is not necessary.
>
> Hmmm...is this a grouping problem or an aggregate problem? Or both? The first
> query above should have the data sorted before aggregating, shouldn't it, or I
> am still missing a piece of this puzzle?
>
> darrenk
The hash should work. If the hash key is built on the group-by items,
then any row with the same entries in these columns will get hashed to
the same result row. At this point, it should be fairly easy to
perform aggregation (test and substitute for min and max, add for
sum,avg, etc).
Ocie
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1998-01-28 23:58:54 | Re: [HACKERS] postmaster crash and .s.pgsql file |
Previous Message | Darren King | 1998-01-28 17:52:18 | Re: [HACKERS] No: implied sort with group by |