Сколько обходов использует pg_query_params?

Question

Вопрос из двух частей.

1. В соответствии с названием, сколько циклических переходов использует pg_query_params?
2. Как подсчитать количество обращений к базе данных в моих скриптах?

Пример кода:

        $result = pg_query_params($pg_connection, <<<'EOQ'
INSERT INTO accounts (username, salt, hash, created, lastlogin)
    VALUES ($1, $2, $3, NOW(), NOW())
EOQ
                    , array($username, $salt, crypt($password, $salt)));

Спасибо.

Answer 1

pg_query_params () использует только одну передачу туда и обратно.Это особенность проводного протокола postgres, который позволяет отправлять запрос и параметры по отдельности, но без необходимости ждать ответа между ними.

Вы не можете действительно считать циклы, но вы можете посмотреть на исходный код илипросто посмотрите на время запроса при запросе к серверу с ненулевым временем пинга.

FYI, на сервере postgres, работающем на localhost, использование реально подготовленного оператора (т. е. PDO) выполняется намного медленнее (> 2x ...) для очень простых запросов (потому что он использует 2 цикла), чем pg_query_params ().

---

О подготовленных выражениях: у Postgres есть несколько способов выполнить запрос.

• Необработанный SQL со встроенными параметрами (способ oldskool): он по-прежнему полезен и является единственным способом построения списков IN () или VALUES ().Надлежащий уровень API, который обрабатывает кавычки, является обязательным (как DBAPI на языке Python).Любой след прямого вызова метода quote () в пользовательском коде является признаком проблемы!

• Одноразовые подготовленные операторы (pg_query_params): это особый случай протокола, в котором "PrepareСообщения "и" Выполнить с параметрами "отправляются в одном пакете.С точки зрения пользователя, он примерно такой же скорости, что и необработанный SQL (одна поездка туда и обратно), немного меньше затрат на синтаксический анализ на сервере (может быть полезно для вставки больших данных) и автоматически защищен (без цитирования).Вам необходимо заменить списки IN () и VALUES () массивами (= ANY, unnest ()).Postgres будет использовать значения параметров в плане запроса, поэтому вы получите хорошие планы.

• Реально подготовленные заявления (PDO, подготовка и т. Д.): Это хорошо, если вы хотите заплатитьПланирование стоит один раз и выполняется много раз (хотя, как правило, SQL-запрос внутри цикла является ошибкой).Два обхода, намного медленнее для простого SELECT по первичному ключу.Может забрать память postgres, если вы подготовите миллион планов, не отменяя их впоследствии.Параметры обычно НЕ используются при планировании запросов (поскольку они недоступны), поэтому вы можете получить неоптимальные планы запросов.В конце концов, это довольно бесполезно для приложения PHP, где ни Postgres, ни PHP не будут кэшировать планы запросов.Если вы используете сервер приложений, который хранит кэшированные планы запросов для простых простых запросов, то подготовленный простой запрос (например, SELECT по первичному ключу) будет использовать гораздо меньше ресурсов сервера, чем необработанный (довольно быстрее, чем самопровозглашенная скорость).Король MyISAM на самом деле).