* setup:
  - perf:
sudo sysctl kernel.perf_event_paranoid=-1
sudo sysctl kernel.kptr_restrict=0
persist
sudo tee /etc/sysctl.d/60-perf.conf <<EOF
kernel.kptr_restrict=0
kernel.perf_event_paranoid=-1
EOF

  - ./configure CFLAGS='-fno-omit-frame-pointer -ggdb -O2' ...

* Resources
  - https://wiki.postgresql.org/wiki/Profiling_with_perf

- perf top, record & report, stat intro
- example cycle profile
- explain syscall/probe method of measuring contention
  - user defined tracepoints have higher overhead
  - system call profiling has higher overhead than cycle sampling
perf
perf probe -x /home/andres/build/postgres/dev-optimize/vpath/src/backend/postgres -a s_lock
perf probe -x /home/andres/build/postgres/dev-optimize/vpath/src/backend/postgres -a
- explain speculative/pipelined execution
  - pipelined execution: work on multiple executions at the same time
    - show decoding, operator fetch, arithmetic instruction, storing of result
  - frontend: parses instructions, predicts branches
  - backend: executeds parsed instructions
  - queue of outstanding executions
    - each outstanding execution is independent
    - no outstanding executions anymore: frontend too slow
    - queue full: backend too slow
  - speculative execution:
    - execute stuff whiteout it being definitely neede
    - outstanding executions might actually not be independent
  - e.g. explains why the "wrong" execution is shown being expensive
- mention ocperf
- do example profile
  - show SearchSysCache() overhead
  - notice how that overhead is mostly in memcpy()



We'll cover:

* how to compile postgres to get meaningful profiles
* overview over the perf utilities
* taking and interpreting CPU profiles
* measuring lock contention for heavyweight-, lightweight- and spin-locks
* a short introduction over modern CPU architecture, and what that means
  for writing code and profiling code
* defining custom tracepoints, and what to use them for
"