On 23 June 2013 03:16, Stephen Frost <sfr...@snowman.net> wrote: > Will think on it more.
Some other thoughts related to this... * Why are we building a special kind of hash table? Why don't we just use the hash table code that we in every other place in the backend. If that code is so bad why do we use it everywhere else? That is extensible, so we could try just using that. (Has anyone actually tried?) * We're not thinking about cache locality and set correspondence either. If the join is expected to hardly ever match, then we should be using a bitmap as a bloom filter rather than assuming that a very large hash table is easily accessible. * The skew hash table will be hit frequently and would show good L2 cache usage. I think I'll try adding the skew table always to see if that improves the speed of the hash join. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers