>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
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
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.
In response to
pgsql-performance by date
|Next:||From: Greg Stark||Date: 2008-11-30 13:02:51|
|Subject: Re: Increasing GROUP BY CHAR columns speed|
|Previous:||From: Kevin Grittner||Date: 2008-11-28 22:28:42|
|Subject: Re: Memory Allocation|