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.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
