From: | tgl(at)postgresql(dot)org (Tom Lane) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Fix performance problems in multi-batch hash joins by ensuring |
Date: | 2007-06-01 15:58:09 |
Message-ID: | 20070601155809.D3B129FB8A9@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Log Message:
-----------
Fix performance problems in multi-batch hash joins by ensuring that we select
a well-randomized batch number even when given a poorly-randomized hash value.
This is a bit inefficient but seems the only practical solution given the
constraint that we can't change the hash functions in released branches.
Per report from Joseph Shraibman.
Applied to 8.1 and 8.2 only --- HEAD is getting a cleaner fix, and 8.0 and
before use different coding that seems less vulnerable.
Tags:
----
REL8_1_STABLE
Modified Files:
--------------
pgsql/src/backend/access/hash:
hashfunc.c (r1.45.2.1 -> r1.45.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/hash/hashfunc.c.diff?r1=1.45.2.1&r2=1.45.2.2)
pgsql/src/backend/executor:
nodeHash.c (r1.96.2.2 -> r1.96.2.3)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/nodeHash.c.diff?r1=1.96.2.2&r2=1.96.2.3)
pgsql/src/include/access:
hash.h (r1.63.2.1 -> r1.63.2.2)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/access/hash.h.diff?r1=1.63.2.1&r2=1.63.2.2)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-06-01 17:38:44 | pgsql: Buy back some of the cycles spent in more-expensive hash |
Previous Message | Tom Lane | 2007-06-01 15:58:02 | pgsql: Fix performance problems in multi-batch hash joins by ensuring |