From b1055c51e32d766a884b164effa77cb6bcee167f Mon Sep 17 00:00:00 2001 From: greaber Date: Sun, 24 Jul 2016 16:05:27 -0500 Subject: [PATCH] Updated Prepared Statements (markdown) --- Prepared-Statements.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Prepared-Statements.md b/Prepared-Statements.md index 55298a6..b5bfd95 100644 --- a/Prepared-Statements.md +++ b/Prepared-Statements.md @@ -20,8 +20,7 @@ Parameters may not be DDL: - `select name from $1 where emp_id=$2` – illegal – table cannot be parameter - `select name from $1.emp where emp_id=$2` – illegal – schema cannot be parameter -Parameterized queries in postgres are planned for before each execution, so they provide safety -but not speed. +Parameterized queries in postgres are parsed, analyzed, rewritten, and planned before each execution, so they provide safety but not speed. With tagged template string literals introduced in ECMAScript 6, parameterized queries can be written more easily with a simple tag function: @@ -59,13 +58,13 @@ A workaround is to do 2 separate queries and using whatever type of async flow c ##Prepared Statements## -A prepared statement lets postgres parse, analyze, and rewrite a statement just once instead of every time it is used. Postgres may also plan the query just once, if it estimates that there is little benefit from constructing parameter-specific plans. +A prepared statement lets postgres parse, analyze, and rewrite a statement just once instead of every time it is used. Postgres may also plan the query just once, if it estimates that there would be little benefit from constructing parameter-specific plans. -Prepared statements also provide a barrier to SQL injection attacks(as parameterized queries also do). +Prepared statements also provide a barrier to SQL injection attacks (as parameterized queries also do). ### Performance of prepared statements ### -Some users have found that prepared statements rarely improve performance by very much and often actually hurt it. A rule of thumb is to start by using no prepared statements and only consider using a prepared statement, or alternatively a function, if you have a bottleneck with a particular query that is a very large number of times. You may see a benefit particularly when a query contains very complex WHERE and JOIN clauses. +Some users have found that prepared statements rarely improve performance by very much and often actually hurt it. A rule of thumb is to start by using no prepared statements and only consider using a prepared statement, or alternatively a function, if you have a bottleneck with a particular query that is executed a very large number of times. You may see a benefit particularly when a query contains very complex WHERE and JOIN clauses. ### Prepared statements and session ###