From e8c8730157d00de24b5fc04af1317f4043347a19 Mon Sep 17 00:00:00 2001
From: Oliver <okennedy@buffalo.edu>
Date: Mon, 28 Oct 2019 17:26:11 -0400
Subject: [PATCH] work in progress slides

---
 .../2019fa/slide/2019-10-28-ThreadsToData.erb | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 src/teaching/cse-662/2019fa/slide/2019-10-28-ThreadsToData.erb

diff --git a/src/teaching/cse-662/2019fa/slide/2019-10-28-ThreadsToData.erb b/src/teaching/cse-662/2019fa/slide/2019-10-28-ThreadsToData.erb
new file mode 100644
index 00000000..70b2fc29
--- /dev/null
+++ b/src/teaching/cse-662/2019fa/slide/2019-10-28-ThreadsToData.erb
@@ -0,0 +1,37 @@
+---
+template: templates/cse662_2019_slides.erb
+title: Thread Pinning Tricks
+date: October 28
+---
+
+<!--
+- Crescando Overview 
+  - Goals: 
+    - Low latency vs Predictable Latency
+    - Workload: OLTP-style; Simple, but high throughput queries and updates
+  - Challenges:
+    - Inter-query interference (Locking is a no-go)
+    - Caching: High variability in data resources being accessed
+  - Observation: 
+    - Lots of overlap between queries in workload
+
+- Miniaturize: 
+  - Assign a CPU thread to a chunk of data
+  - Maximize throughput on this one chunk
+    - Branching a problem
+    - Cache lines a problem
+
+- Coalescing Operations
+  - Classic Scan: Loop over Individual Operations
+  - Elevator Scan: 
+    - Loop over Data
+      - Stream in each chunk of data to all operators in parallel
+      - Allow operators to attach in between any chunks (detach after 1 full scan)
+    - Discuss: 
+      - Why is this ok / better?
+      - When does this fail?
+  - 
+
+
+
+-->