| From: | "Andrus" <kobruleht2(at)hot(dot)ee> | 
|---|---|
| To: | "Scott Carey" <scott(at)richrelevance(dot)com>, "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> | 
| Cc: | <pgsql-performance(at)postgresql(dot)org> | 
| Subject: | Re: Increasing GROUP BY CHAR columns speed | 
| Date: | 2008-11-29 17:43:50 | 
| Message-ID: | 926CBE5E333B42E79C82E5C50C51ACB8@andrusnotebook | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
>I'm still not sure why the planner chose to sort rather than hash with 
>oversized work_mem (is there an implied order in the query results I 
>missed?).
Group by contains decimal column exchrate. Maybe pg is not capable to use 
hash with numeric datatype.
>   My guess is that this query can still get much faster if a hash is 
> possible on the last part.  It looks like the gain so far has more to do 
> with sorting purely in memory which reduced the number of compares 
> required.  But that is just a guess.
I fixed this by adding cast to :::float
bilkaib.exchrate:::float
In this case query is much faster.
Hopefully this will not affect to result since numeric(13,8) can casted to 
float without data loss.
Andrus.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2008-11-30 13:02:51 | Re: Increasing GROUP BY CHAR columns speed | 
| Previous Message | Kevin Grittner | 2008-11-28 22:28:42 | Re: Memory Allocation |