Prepared statement
Wzorzec SQL: wysyłasz szablon zapytania z miejscami na parametry ($1, ?), a wartości przekazujesz osobno. Dwie główne korzyści: ochrona przed wstrzykiwaniem SQL (parametry nigdy nie są interpretowane jako SQL) oraz buforowanie planu wykonania.
Cykl życia: PREPARE (wysłanie szablonu, działa parser i planer) → EXECUTE (wysłanie wartości, uruchomienie planu). Kolejne wywołania pomijają parsowanie i planowanie i przechodzą prosto do wykonania. Koszt: planer tworzy plan ogólny, który dla konkretnych wartości bywa suboptymalny. W PostgreSQL po pięciu wywołaniach z planem ogólnym system sprawdza, czy plan dedykowany nie byłby lepszy. Pułapka z pulami połączeń: prepared statements są przypisane do sesji, więc gdy połączenia z puli są współdzielone globalnie, instrukcje trzeba często przygotowywać na nowo. PgBouncer w trybie transakcyjnym psuje prepared statements.