Hash joins and bloom filters at AMIS25

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Bloom filters
Toon Koppelaars
Real World Performance team
Database Server Technologies

Hash function
Hash joins
Bloom filters
Agenda
Examples

Hash joins and Bloom filters
• Bloom filters (BF) introduced in 10gR2
– Enable CBO to “filter early” in hash joins
– Used automatically, visible in execution plan
• Implemented to speed up large parallel hash joins (DWH/BI)
– BF’s prevent unnecessary row-transport between parallel query slave sets
• As of 11.2.0.4 BF’s may also show up in serial plans

Hash joins explained
-----------------------------------
| Id | Operation | Name |
-----------------------------------
| 0 | SELECT STATEMENT | |
|* 1 | HASH JOIN | |
| 2 | TABLE ACCESS FULL| DEPT |
| 3 | TABLE ACCESS FULL| EMP |
-----------------------------------
Predicate Information
---------------------------------------
1 - access("D"."DEPTNO"="E"."DEPTNO")
select *
from emp e, dept d
where d.deptno = e.deptno

What is a hash-function?
– Hash function application is cheap
– Hash values are typically “evenly
distributed” in range
• Irrespective of distribution of input values
– Collisions can occur
• Two domain values map to same hash value
• Since #domain >> #range
Domain Range
Hash
function
Digital data
Byte strings of any length
“Hash values”
Offset between
[0..some-power-of-2 minus 1]

Phase 1: build hash table (DEPT)
-----------------------------------
-----------------------------------
-----------------------------------
---------------------------------------
select *
from emp e, dept d
s
c
a
n
Apply hash function to DEPT.DEPTNO
to find in which bucket to store
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Bucketized hash-table in PGA memory
Build phase

Phase 1 done
-----------------------------------
-----------------------------------
-----------------------------------
---------------------------------------
select *
from emp e, dept d
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Phase 2: probe 2nd table (EMP)
-----------------------------------
-----------------------------------
-----------------------------------
---------------------------------------
select *
from emp e, dept d
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
s
c
a
n
Apply hash function to EMP.DEPTNO
to find in which bucket to probe for
matching DEPT record
If match found: join and return row
Probe phase

Hash joins parallel execution plan
-------------------------------------------------------------------------
| Id | Operation | Name | TQ |IN-OUT| PQ Distrib |
-------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | |
| 1 | PX COORDINATOR | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10002 | Q1,02 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | Q1,02 | PCWP | |
| 4 | PX RECEIVE | | Q1,02 | PCWP | |
| 5 | PX SEND HASH | :TQ10000 | Q1,00 | P->P | HASH |
| 6 | PX BLOCK ITERATOR | | Q1,00 | PCWC | |
| 7 | TABLE ACCESS FULL| DEPT | Q1,00 | PCWP | |
| 8 | PX RECEIVE | | Q1,02 | PCWP | |
| 11 | TABLE ACCESS FULL| EMP | Q1,01 | PCWP | |
-------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
QC
P10
P11
P12
P00
P01
P02
Slave set 2 Slave set 1
Assuming DOP = 3

Build phase
QC
P10
P11
P12
P00
P01
P02
Lines 7,6,5: Scan DEPT, hash send to SS2
-------------------------------------------------------------------------
-------------------------------------------------------------------------
|* 3 | HASH JOIN | | Q1,02 | PCWP | |
| 4 | PX RECEIVE | | Q1,02 | PCWP | |
| 8 | PX RECEIVE | | Q1,02 | PCWP | |
-------------------------------------------------------------------------
---------------------------------------------------
Hash PQ Distrib:
conceptually distributes rows based on
mod(hash(deptno),3)

Build phase
QC
P10
P11
P12
Line 4/3: Build hash table for DEPT rows received
-------------------------------------------------------------------------
-------------------------------------------------------------------------
|* 3 | HASH JOIN | | Q1,02 | PCWP | |
| 4 | PX RECEIVE | | Q1,02 | PCWP | |
| 8 | PX RECEIVE | | Q1,02 | PCWP | |
-------------------------------------------------------------------------
---------------------------------------------------
P00
P01
P02
(still scanning/sending)

Hash joins parallel execution plan
QC
-------------------------------------------------------------------------
-------------------------------------------------------------------------
|* 3 | HASH JOIN | | Q1,02 | PCWP | |
| 4 | PX RECEIVE | | Q1,02 | PCWP | |
| 8 | PX RECEIVE | | Q1,02 | PCWP | |
-------------------------------------------------------------------------
---------------------------------------------------
P10
P11
P12
P00
P01
P02
Build phase ready

Probe phase
QC
-------------------------------------------------------------------------
-------------------------------------------------------------------------
|* 3 | HASH JOIN | | Q1,02 | PCWP | |
| 4 | PX RECEIVE | | Q1,02 | PCWP | |
| 8 | PX RECEIVE | | Q1,02 | PCWP | |
-------------------------------------------------------------------------
---------------------------------------------------
P10
P11
P12
P00
P01
P02
Lines 11,10,9: Scan EMP, hash send to SS2
Same mod(hash(deptno),3)
distribution used

Probe phase
QC
-------------------------------------------------------------------------
-------------------------------------------------------------------------
|* 3 | HASH JOIN | | Q1,02 | PCWP | |
| 4 | PX RECEIVE | | Q1,02 | PCWP | |
| 8 | PX RECEIVE | | Q1,02 | PCWP | |
-------------------------------------------------------------------------
---------------------------------------------------
P10
P11
P12
Line 8/3: Join/probe hash table for EMP rows received
P00
P01
P02

Probe phase
QC
-------------------------------------------------------------------------
-------------------------------------------------------------------------
|* 3 | HASH JOIN | | Q1,02 | PCWP | |
| 4 | PX RECEIVE | | Q1,02 | PCWP | |
| 8 | PX RECEIVE | | Q1,02 | PCWP | |
-------------------------------------------------------------------------
---------------------------------------------------
P10
P11
P12
Lines 2/1: Receive resulting joined rows
P00
P01
P02
(still receiving/joining)
Point to be made:
Inter slave set traffic = expensive
as 2nd table would be much larger

Filter early
• What do we mean by “filter early”?
– In the hierarchical execution plan tree
– Eliminate rows as soon (early) as possible
– Preventing their (expensive) flow through parent execution stages in plan

Filter early: join example
select d.dname,e.ename
from dept d, emp e
and d.deptno between 130 and 150
Remember this plan
BF’s operate in same way
--------------------------------------------------------
--------------------------------------------------------
| 2 | TABLE ACCESS BY INDEX ROWID BATCHED| DEPT |
|* 3 | INDEX RANGE SCAN | DEPT_PK |
|* 4 | TABLE ACCESS FULL | EMP | <== Filter!
--------------------------------------------------------
---------------------------------------------------
3 - access("D"."DEPTNO">=130 AND "D"."DEPTNO"<=150)
4 - filter(("E"."DEPTNO">=130 AND "E"."DEPTNO"<=150)) <== Filter!

Bloom filter concept

• Memory structure representing a set of values (say S)
– “representing”  member values are encoded in specific manner
• Memory structure can be used to answer:
– Is a given value x, member of set S?
• Two possible answers
– Definitely not
– Possibly yes
Two operators on structure:
1) Add value x
2) Test membership
Conceived by Burton Howard Bloom in 1970

• BF(m,k)
– m = size of memory structure in bits  array of m bits
– k = number of hash functions used to encode value (hf1,…,hfk)
• Range of hash functions is: [0..m]
Bit array initially filled with 0’s
• Adding (encoding) a value x:
– Apply each hash-function to value x  this produces k hash-values
– Set bit in array at each hash-value’s position

Bloom filter: adding value 2
Assuming 3 hash functions used
hf1
hf2
hf3

Note:
one of hashes of 6 is same as
one of hashes of 2

Bloom filter: testing for membership
• Once bloom filter is populated with complete set, we can test for
membership of any given value
– By just applying hash-functions to given value
– And checking if all hashed positions in bit-array are filled with 1
• If any not filled  then definitely not a member of the set
• If all filled  then possibly (!) member of the set

Testing value 6
Possibly yes

Testing value 14
Definitely not

False positives possible
• Likelihood increases when bit-array is sized too small
• Demo: https://www.jasondavies.com/bloomfilter/

Bloom filter sizing
• CBO uses estimated NDV to size Bloom filter
• Number of Distinct Values
• Demo: http://hur.st/bloomfilter?n=1000000&p=0.01

Why use Bloom filters?
1. Memory structure is small
– Around 9-10 bits per (distinct) element required for a 1% false positive probability
2. Add and test operators are fast
– Cheap hash + fast set/test bit-operations
 Bloom filters are cheap to create, use and dispose of, on-the-fly

How can Bloom filter help filter early in hash joins?
• BF use-cases in hash-join are of the form:
– In BUILD stage of execution plan: BF CREATE
• All join-column values of build-table added to BF
• BF filter = bit signature of join condition
– Then during PROBE stage of execution plan: BF USE
• Every join-column value of probe-table tested against BF
• BF filter used to filter ‘definitely not member’ cases

Early filtering
HASH JOIN
DEPT EMP
Where-clause predicate
Bloom filter
creation Bloom filter
use
• Bloom filter encodes subset of
DEPT PK join-values
• Used during scan of EMP FK join-
values
• Bloom filter prevents flow of EMP
rows to Hash-Join operator for
which there would not be
matching DEPT row

Bloom filter examples
• Parallel join filter
• Serial subquery filter
• Multiple BF’s (rightdeep tree)
• Bloom pruning filter

Parallel join filter
select d.dname,e.ename
from dept d, emp e
and d.loc = 'UTRECHT'
---------------------------------------------
---------------------------------------------
| 1 | PX COORDINATOR | |
| 2 | PX SEND QC (RANDOM) | :TQ10002 |
| 4 | JOIN FILTER CREATE | :BF0000 |
| 5 | PX RECEIVE | |
| 6 | PX SEND HASH | :TQ10000 |
| 7 | PX BLOCK ITERATOR | |
|* 8 | TABLE ACCESS FULL| DEPT |
| 9 | PX RECEIVE | |
| 10 | PX SEND HASH | :TQ10001 |
| 11 | JOIN FILTER USE | :BF0000 |
| 12 | PX BLOCK ITERATOR | |
|* 13 | TABLE ACCESS FULL| EMP |
---------------------------------------------
---------------------------------------------------
8 - filter("D"."LOC"='UTRECHT')
13 - filter(SYS_OP_BLOOM_FILTER(:BF0000,"E"."DEPTNO"))
False positives caught in line 3
What is saved?
1. Less rows distributed SS1  SS2
during probe phase
2. Bit vs byte-string operations
Filter on non-join column (LOC)
used to ‘early filter’ EMP rows
hf1

Serial subquery filter
select d.dname,e.disnm
from dept d
,(select deptno
,count(distinct ename)
as disnm
from emp
group by deptno) e
where d.loc='UTRECHT‘
and d.deptno = e.deptno
--------------------------------------------------------------
| Id | Operation | Name | Starts | A-Rows |
--------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 11 |
| 1 | HASH GROUP BY | | 1 | 11 |
|* 2 | HASH JOIN | | 1 | 44 |
| 3 | JOIN FILTER CREATE | :BF0000 | 1 | 11 |
|* 4 | TABLE ACCESS FULL | DEPT | 1 | 11 |
| 5 | VIEW | VM_NWVW_1 | 1 | 44 |
| 6 | HASH GROUP BY | | 1 | 44 |
| 7 | JOIN FILTER USE | :BF0000 | 1 | 44 |
|* 8 | TABLE ACCESS FULL| EMP | 1 | 44 |
--------------------------------------------------------------
---------------------------------------------------
2 - access("D"."DEPTNO"="$vm_col_2")
4 - filter("D"."LOC"='UTRECHT')
8 - filter(SYS_OP_BLOOM_FILTER(:BF0000,"DEPTNO"))BF push through GroupBy

Multiple Bloom filters
part
date_dim supplier
Line
order

Bloom pruning filter (11g)
P0
P1
P2
P3
P4
FACT partitioned
DIM
INSERT INTO FACT(...,DIM_FK,...)
VALUES(...,42,...)
Compute_P#_for_FACT(42)

Bloom pruning filter (11g)
• Shows up as “Partition join filter create”
– When joining DIM to FACT and join-column is input for partitioning scheme of FACT
– Build phase:
• FACT’s partition function is applied to DIM PK values to find P#’s of FACT that would hold such values
• These P#’s are added to Bloom filter
– Probe phase:
• Bloom filter is used when scanning FACT
• Only partitions whose P#’s are in Bloom filter will be scanned
P0
P1
P2
P3
P4
FACT partitioned
DIM

Bloom pruning filter
---------------------------------------------------------------------
| Id | Operation | Name | Pstart| Pstop |
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | |
| 1 | SORT AGGREGATE | | | |
| 2 | PX COORDINATOR | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10001 | | |
| 4 | SORT AGGREGATE | | | |
|* 5 | HASH JOIN | | | |
| 6 | BUFFER SORT | | | |
| 7 | PART JOIN FILTER CREATE| :BF0000 | | |
| 8 | PX RECEIVE | | | |
| 9 | PX SEND BROADCAST | :TQ10000 | | |
|* 10 | TABLE ACCESS FULL | DATE_DIM | | |
| 11 | PX BLOCK ITERATOR | |:BF0000|:BF0000|
|* 12 | TABLE ACCESS FULL | STORE_SALES |:BF0000|:BF0000|
---------------------------------------------------------------------

Final remarks
• Bloom filter are pushed down to storage cells and DBIM scans
• SQL Monitor report has details on Bloom filter
– V$sql_join_filter
• Hints px_join_filter() / no_px_join_filter()
• alter session set events 'trace[RDBMS.Bloom_filter] …'
• Event 10128 Bloom pruning filter

Hash function
Hash joins
Bloom filters
Examples
Questions?
Email: toon.koppelaars@oracle.com
Twitter: @toonkoppelaars

Shameless plug…
• community.oracle.com
• community.oracle.com/ideas
• community.oracle.com/ideas/13028
• If you think declarative generic multi-row constraints are useful
go check it out and vote

Hash joins and bloom filters at AMIS25

More Related Content

What's hot (20)

Similar to Hash joins and bloom filters at AMIS25 (20)

More from Getting value from IoT, Integration and Data Analytics (20)

Recently uploaded (20)

Hash joins and bloom filters at AMIS25