]> granicus.if.org Git - postgresql/commit
Increase number of hash join buckets for underestimate.
authorKevin Grittner <kgrittn@postgresql.org>
Mon, 13 Oct 2014 15:16:36 +0000 (10:16 -0500)
committerKevin Grittner <kgrittn@postgresql.org>
Mon, 13 Oct 2014 15:16:36 +0000 (10:16 -0500)
commit30d7ae3c76d2de144232ae6ab328ca86b70e72c3
tree1ef25acf6cbb5843eff05a82e3282d4c314d7bea
parent494affbd900d1c90de17414a575af1a085c3e37a
Increase number of hash join buckets for underestimate.

If we expect batching at the very beginning, we size nbuckets for
"full work_mem" (see how many tuples we can get into work_mem,
while not breaking NTUP_PER_BUCKET threshold).

If we expect to be fine without batching, we start with the 'right'
nbuckets and track the optimal nbuckets as we go (without actually
resizing the hash table). Once we hit work_mem (considering the
optimal nbuckets value), we keep the value.

At the end of the first batch, we check whether (nbuckets !=
nbuckets_optimal) and resize the hash table if needed. Also, we
keep this value for all batches (it's OK because it assumes full
work_mem, and it makes the batchno evaluation trivial). So the
resize happens only once.

There could be cases where it would improve performance to allow
the NTUP_PER_BUCKET threshold to be exceeded to keep everything in
one batch rather than spilling to a second batch, but attempts to
generate such a case have so far been unsuccessful; that issue may
be addressed with a follow-on patch after further investigation.

Tomas Vondra with minor format and comment cleanup by me
Reviewed by Robert Haas, Heikki Linnakangas, and Kevin Grittner
src/backend/commands/explain.c
src/backend/executor/nodeHash.c
src/include/executor/hashjoin.h