Orca: A Modular Query Optimizer Architecture for VMware Greenplum
summary
Explains how Orca replaces PostgreSQL planning with a memo-based search that registers logical-to-logical and logical-to-physical transforms, uses a metadata provider API to pull type/partition/index/statistics, and enforces distribution and ordering via a distribution enforcement layer so colocated hash joins and partition elimination coexist. Shows code-level hooks for new operators, three pluggable cost models, a translator that emits Postgres plan statements, current limits (limited materialized view support, prepared-statement fallback to Postgres, cardinality/correlated-stats challenges) and practical deployment experience.
AI-written summary · about
chapters (28)
- 0:00Introduction
- 1:23Overview
- 2:50Who am I
- 3:57Greenplum
- 5:52Random
- 7:07Partitioning
- 9:33Disclaimers
- 9:48Live Journey
- 10:23Query Optimization
- 11:00Why Orca
- 15:03Query Optimizer
- 15:54Performance
- 17:54Postgres
- 18:53Orca vs Postgres
- 22:23Orca Communication
- 23:33Metadata Provider API
- 24:58Constant Expression Evaluation
- 26:16Multiple Databases
- 26:46Modular and extensible
- 27:56Optimization tools
- 29:32Steps in query processing
- 30:32Preprocessing
- 32:52Expiration
- 34:23Join Order
- 35:36Required Properties
- 41:42Physical Implementation
- 47:27Whats Next
- 52:26Orca Code
related talks
01h 09mReplacing Oracle Features in PostgreSQL: HA, Functions & Extensibility
46mBeyond Good and ORMs
07mSolving PostgreSQL wicked problems
27mOSSom for Better Oracle to Postgres Assessments
04h 15mTopical Edition on Databases - Track 2
50mFrom Transactions to Intelligence: Postgres for Open AI & Analyti
30mGreenplum Database — massive parallel processing with a shared-nothing architecture based on Postgres
45mBeing mindful of query optimizer