Ускорение пользовательских функций в PostgreSQL

Мы ещё в процессе перевода последних наших проектов с «Оракла» на «Постгрес», поэтому всё ещё не закончили избавляться от характерных для диалекта «Оракла» функций, тащим их с собой — пока так проще.

В попытке как-то их ускорить, наткнулся на странность. Возможно это где-то описано, я пока не нашёл это место в руководстве.

Ниже две функции на разных языках, поддерживаемых «Постгресом», по смыслу идентичные — обе представляют собой замену функции NVL2 «Оракла» над целыми числами:
CREATE FUNCTION nvl2_plpgsql(a numeric, b numeric, c numeric) RETURNS numeric AS '
BEGIN
  IF a IS NULL
    THEN RETURN c;
    ELSE RETURN b;
  END IF;
END;
' LANGUAGE plpgsql IMMUTABLE;

CREATE FUNCTION nvl2_sql(a numeric, b numeric, c numeric) RETURNS numeric AS '
SELECT CASE WHEN a IS NULL THEN c ELSE b END;
' LANGUAGE SQL IMMUTABLE;
Будет ли какая-то разница в производительности? Посмотрим на тесты:

p95=# EXPLAIN ANALYZE SELECT nvl2_plpgsql(g, 0, 0) FROM generate_series(1, 10000000) _(g);

Planning time: 0.066 ms Execution time: 38881.927 ms

p95=# EXPLAIN ANALYZE SELECT nvl2_sql(g, 0, 0) FROM generate_series(1, 10000000) _(g);

Planning time: 0.253 ms Execution time: 15435.231 ms


Как ни странно, функция на чистом ЭсКуЭле быстрее. Судя по моим экспериментам, так всегда. Иногда результаты различаются вдвое, иногда на порядок — зависит от того, что она делает, но как правило быстрее, обратных примеров я ещё не встречал.

Это неплохое подспорье, так как у нас такие функции встречаются не только в самих запросах, но и в функциональных индексах, значит ускорятся не только чтения, но и вставки.
Комментировать
11 апреля 2017 20:24

Mosh

Клиент mosh (40.65КиБ)
Окно клиента, когда пропало соединение

Погонял несколько дней в качестве клиента «мош» — «мобильный шелл». Хорошая штука, логинится через эсэсаш, далее поднимает на удалённой стороне свой сервер и открывает свой шифрованный канал через ЮДиПи. Ключи авторизации тоже естественно поддерживаются.

Штука в том, что при разрыве соединения сессия не пропадает, а терпеливо ждёт возобновления — такая помесь эсэсаша и скрина, смены айпи ей тоже не страшны. Другая фишка — если канал пропал или на нём высокие задержки, делаются локальные предсказания поведения курсора, то есть можно печатать и передвигаться по тексту, даже если соединения нет.

Пока всё работает не очень стабильно, но всё равно выглядит как шаг вперёд. У меня время от времени пропадают буквы на выводе самых обычных команд, иногда по экрану скачет курсор или текст выводится не в том месте, но в целом пользовать можно.

Ставится просто — поддерживаются все основные системы, ставите на обе стороны, запускаете из командной строки (mosh имя_сервера вместо ssh имя_сервера) и всё работает.
5 комментариев
9 апреля 2017 20:08

Запрос на pg_field_type

Страшно удивился, когда увидел в логах «Постгреса» запрос, которого не было в коде нашего продукта:
select oid,typname from pg_type
Как-то сразу догадался, что он порождается вызовом pg_field_type, который у нас используется, чтобы прозрачно для верхнего уровня обрабатывать тип bytea. Заменил вызов на pg_field_type_oid и запрос пропал.

Проблемы, конечно, особой в этом нет — запрос плёвый, тем более он выполняется только при первом вызове pg_field_type, но как-то неприятно, когда на каждый запуск прилетает полторы тысячи с гаком строк, которые я не заказывал, люблю контролировать такие вещи.
Комментировать
7 апреля 2017 08:16

Коммит миграций кусками с помощью psql

Я ещё не так давно работаю с «Постгресом» и раз в месяц натыкаюсь на что-то неожиданное.

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

В «Оракле» такую миграцию наши ребята, насколько я знаю, разбивали хранимой процедурой на части и коммитили внутри кусками по миллиону, в «Постгресе» так нельзя — блок на языке PL/pgSQL выполняется в собственной транзакции и она прервётся при попытке сделать COMMIT. Автономных транзакций нет.

Испытания на тестовом стенде, приближенном к промышленному, показали, что единым куском обновить не получится — на мастере и слейве первой очереди кончилось место и стенд развалился. Надо было найти какой-то эквивалент сбросу миграции в цикле, по типу того как это делается в «Оракле».

Гугление рецептов принесло способ, который заключается в том, что мы создаём соединение из базы в в себя же и шлём запросы в это соединение. Говорят работает, но способ мне показался муторным, пришлось придумать свой.
DO $$
  DECLARE
    max_id table.id % TYPE;
    query TEXT;
BEGIN
  -- делим таблицу на куски по миллиону, теперь в max_id у нас номер последнего куска
  SELECT CEIL(MAX(id)::float/1000000) INTO max_id FROM mytable;

  -- очищаем файл /tmp/sqlquery
  COPY (SELECT '') TO '/tmp/sqlquery';

  -- айдишники в моём конкретном случае идут с единицы, но более правильно идти с минимума до максимума с шагом
  FOR i IN 0..max_id LOOP
        query = FORMAT(
            'UPDATE mytable '
            'SET something=value '
            'WHERE id BETWEEN ' || i*1000000+1 || ' AND ' || (i+1)*1000000 || ';'
        );

        -- запуск /bin/cat нужен, чтобы дописывать в файл
        EXECUTE  'COPY (SELECT ' || quote_literal(query) || ') TO PROGRAM ''/bin/cat >> /tmp/sqlquery''';
  END LOOP;
END$$;

-- запуск запроса
\i /tmp/sqlquery
Я воспользовался тем, что в накатке миграции у нас участвует утилита psql — официальный консольный клиент к «Постгресу», помимо команд СУБД она умеет выполнять свои собственные команды, чем я и пользуюсь — собираю нужные запросы в файл и запускаю его на выполнение в последней строке.

Обратите внимание на вызов /bin/cat — это важно, так как команда COPY сама не умеет добавлять что-то в файл, она его перезаписывает.
2 комментария
24 марта 2017 08:48

Скриптование меню в статус-баре

В «Маке» очень нехватает одной вещи — лёгкого создания собственных меню в статус-баре. Учить ради этого «Обжектив-Си» или «Свифт» (и ставить «ЭксКод») мне совершенно не хочется, поэтому я поискал готовое. Нашёл ровно одно полусырое решение.

Если кому интересно, то последовательность его прикручивания к системе примерно такова (bolk — моё имя пользователя и требуется установленный brew):
mkdir -p /usr/local/Cellar/ScriptableStatusBar/0.1/bin/
mv ~/Downloads/ScriptableStatusBar-release/usr/local/bin/sbar !:2
mv ~/Downloads/ScriptableStatusBar-release/Applications/ 
    /usr/local/Cellar/ScriptableStatusBar/0.1
brew link ScriptableStatusBar
open /usr/local/Cellar/ScriptableStatusBar/0.1/Applications/

# Тут надо утянуть открывшееся приложение в «Объекты входа»
# и ещё запустить его в открывшемся окне, разрешив ему в принципе запускаться
Очень неудобно и несколько недоделано. Хотелось бы, чтобы из шелла можно было добавить/удалить пункт меню и сменить иконку. Сейчас это тоже можно, но полной переинициализацией и, кроме того, убъёшься всё экранировать.

Вооружившись несложной инструкцией, делаем несколько магических пассов:
cat>~/lockkeyboard.sh<<LOCK
#!/bin/ksh

kext=/System/Library/Extensions/AppleUSBTopCase.kext/Contents/PlugIns/AppleUSBTCKeyboard.kext/
case "$1" in
	unlock )
		/sbin/kextload "$kext"
		;;
	lock )
		/sbin/kextunload "$kext"
		;;
esac
LOCK

sudo chown root:staff ~/lockkeyboard.sh
sudo chmod 750 ~/lockkeyboard.sh

sudo cp /dev/stdin /private/etc/sudoers.d/lockkeyboard<<SUDO
bolk    ALL= NOPASSWD: /Users/bolk/lockkeyboard.sh
SUDO

sbar set locker 🔓\
	'Lock:/usr/bin/sudo /Users/bolk/lockkeyboard.sh lock'\
	'Unlock:/usr/bin/sudo /Users/bolk/lockkeyboard.sh unlock'\
	'Quit:/usr/local/bin/sbar remove locker'
И получаем малофункциональную такую менюшечку для блокировки клавиатуры (кстати и увы, если компьютер с заблокированной клавиатурой, у вас уйдёт в блокировку по какой-то причине, то пароль ввести не получится, придётся перезагрузиться): Меню блокировки клавиатуры (22.19КиБ)
Простое меню для блокировки клавиатуры

В принципе можно даже сэмулировать защёлкивание замка и смену пунктов меню «Lock» на «Unlock» и обратно (для этого нужно просто пересоздавать меню после каждой из этих команд с другими пунктами и другим замочком), но это ещё полэкрана костылей, которые мне совсем не хочется на вас вываливать.

Кстати, пункты в меню добавляются в произвольном порядке — программе совершенно плевать в каком порядке вы их задали в параметрах.

Дополнение: нашёл ещё две программы: «БитБар» и «ЭниБар».
8 комментариев
8 марта 2017 19:30

Сила .ssh/config

Извечная задача получить доступ к одной машине через другую чаще всего решается при помощи SSH-туннелей — удобно, пока не приходится получать доступ к группе машин. Недостаток традиционного решения — не всегда удаётся придумать удачное правило выбора портов, чтобы не запутаться как мы должны соединяться, чтобы попасть на нужную машину. SSH-туннель (12.37КиБ)
Пример конфигурационного файла для получения доступа к группе машин

К счастью, есть решение лучше, которое позволяет соединяться через SSH наиболее естественным способом — как будто у нас есть прямой доступ.

Тут нам пригодится файл ~/.ssh/config, служащий для конфигурирования SSH-соединений, я обычно туда вписываю символические имена вместо айпи-адресов, логины и прочую мишуру. Но его возможности несколько шире.

Например на картинке выше у меня конфигурация, которая позволяет к любому айпи-адресу, который начинается с 172.17.0 через машину 172.17.1.131. Вся магия заключается в директиве ProxyCommand — в ней указано, что надо залогиниться на 172.17.1.131 и там запустить команду nc, которая откроет соединение на нужный нам адрес (он будет подставлен вместо «%h»).

Таким образом получается соединение, весь трафик которого без изменений попадает на нужный нам адрес, а уже в этом соединении мы выполняем обычный логин на нужную нам машину. Все аутентификации у меня, естественно, сделаны через сертификаты.
4 комментария
8 марта 2017 16:15

Особенности смены типа в PostgreSQL: text → bytea

При обыденной смене типа колонки в «Постгресе» с текстового типа на бинарный получил ошибку «ERROR: invalid input syntax for type bytea». Запрос довольно рядовой и сюрпризов я не ожидал:
ALTER TABLE tbl ALTER COLUMN colmn TYPE bytea USING colmn::bytea;
Решения нагуглить не удалось, поэтому начал исследовать проблему сам. Бинарным поиском нашёл строку на которой запрос запнулся, потом так же вычислил символ. Им оказался обратный слэш. Заэкранировал его и ошибка пропала:
ALTER TABLE tbl ALTER COLUMN colmn TYPE bytea USING REPLACE(colmn, '\', '\\')::bytea;
Всё отработало нормально, сконвертировалось, слеши получаются из базы как и ожидается — одинарными.
3 комментария
9 февраля 2017 11:14

💢 OCI8: проблемы с переходом на PHP7

Ещё в копилку проблем с ПХП7: если при привязке переменных в Оракле (bind) поля типа LONG/LOB не находятся в конце списка, то вы получите ошибку ORA-24816. Все столбцы таких типов должны быть привязаны последними, в общей куче. Мы пока столкнулись с проблемой только при сохранении (тестирование пока идёт), в итоге в сохраняющем методе модели пересортировали привязки, основываясь на описании модели.
13 комментариев
25 июля 2016 08:34

💢 Проблема с переходом на PHP7: Memcached, часть вторая

В прошлый раз я писал о проблемном Мемкешд в ПХП7 и оказалось, что я не совсем прав. Проблема есть, но её корень я понимал неверно.

Я-то думал, что получение токена cas просто сломали при переезде на следующую версию ПХП, а оказалось это особенность — в ПХП7 используется третья версия модуля, а ней токен получается иначе — надо передать специальный параметр и после вызова токен будет в результирующем массиве.

Черновым кодом это выглядит примерно так (должно работать, но я его не запускал):
if (version_compare(phpversion('memcached'), '3.0.0-dev', '<')) {
	// работаем по-старому
	return $memcached;
} else {
	// возвращаем обёртку
	return new class($memcached) {
	    use \Core\ProxyTrait;

	    public function __construct($mc)
	    {
	        $this->setObject($mc);
	    }

	    public function get($key, callable $cache_cb = null, &$cas_token = null)
	    {
	        $result = $this->obj->get($key, $cache_cb, Memcached::GET_EXTENDED);

	        if ($result === Memcached::GET_ERROR_RETURN_VALUE) {
	            return false;
	        }

	        if ($result) {
	            $cas_token = $result['cas'];
	            return $result['value'];
	        }

	        return $result;
	    }

	    public function getMulti(array $keys, array &$cas_tokens = null, int $flag = null)
	    {
	        $result = $this->obj->getMulti($keys, Memcached::GET_EXTENDED | $flag);

	        if ($result === Memcached::GET_ERROR_RETURN_VALUE) {
	            return false;
	        }

	        if ($result) {
	            $values = [];
	            $cas_tokens = [];

	            foreach ($result as $key => $d) {
	                $values[$key] = $d['value'];
	                $cas_tokens[$key] = $d['cas'];
	            }

	            return $values;
	        }

	        return $result;
	    }
	}
}
Вся мякотка в последнем параметре Memcached::GET_EXTENDED, он заставляет возвращать соответствующие методы не искомое значение, а массив, содержащий в том числе и cas.

Неприятно, что в этой версии ПХП модуль для работы с Мемкешд помечен как «разработческий». В этом свете мне как-то неясна позиция тех, кто уверенно советует использовать ПХП7 в продакшне.
2 комментария
19 июля 2016 11:01

💢 Проблема с переходом на PHP7: Memcached

ПХП7 — огромный шаг для интерпретатора ПХП в плане производительности и потребления памяти, поэтому есть большой соблазн начать переводить на него свои продукты. К сожалению, возросшие показатели дались не бесплатно, а путём сломанной в некоторых местах обратной совместимости, самая яркая проблема, которая из этого вытекает — все модули без исключения надо модифицировать.

Поэтому этот шаг, к ПХП7 очень труден для больших проектов, вроде тех, который разрабатываем мы. Тем не менее, мы медленно, но верно движемся в финишу. Вчера столкнулись с неожиданной сложностью, на которую мне пришлось потратить вечер.

Оказалось, что в модуле Мемкешд для ПХП7 нет реализации получения токена cas в методах get и getMulti (наверняка нет ещё в каких-то), но мы их не используем. Это видно, например, по прототипу:
Method [ <internal:memcached> public method get ] {

  - Parameters [2] {
    Parameter #0 [ <required> $key ]
    Parameter #1 [ <optional> $cache_cb ]
  }
}
Как видите, параметра cas нет вообще (он должен быть последним). Это печальное обстоятельство подтолкнуло меня к исследованию и к ночи я сделал решение. Возможно кому-то пригодится:
class MemcachedPHP7
{
    use \Core\ProxyTrait;

    public function __construct($mc)
    {
        $this->setObject($mc);
    }

    public function get($key, callable $cache_cb = null, &$cas_token = null)
    {
        switch (func_num_args()) {
            case 1:
                return $this->obj->get($key);
            case 2:
                return $this->obj->get($key, $cache_cb);
            default:
                if ($this->obj->getDelayed([$key], true) === false) {
                    return false;
                }

                $res = $this->obj->fetchAll();

                if ($res === false || !$res) {
                    if ($cache_cb !== null) {
                        if ($cache_cb($this->obj, $key, $value)) {
                            $this->obj->set($key, $value);
                        }
                    } else {
                        $value = false;
                    }
                } else {
                    $cas_token = $res[0]['cas'];
                    $value = $res[0]['value'];
                }

                return $value;
        }
    }

    public function getMulti(array $keys, array &$cas_tokens = null)
    {
        if (func_num_args() === 1) {
            return $this->obj->getMulti($key);
        } else {
            if ($this->obj->getDelayed($keys, true) === false) {
                return false;
            }
            $res = $this->obj->fetchAll();

            if ($res === false) {
                return false;
            }

            $cas_tokens = [];
            $values = [];

            $results = array_column($res, null, 'key');

            foreach ($keys as $key) {
                $cas_tokens[$key] = $results[$key]['cas'];
                $values[$key] = $results[$key]['value'];
            }

            return $values;
        }
    }
}
Трейт ProxyTrait я тут не привожу, там идея простая — он тупо проксирует всё, что получает через магические методы __get, __set, __call и прочие, setObject — метод этого трейта. Очень удобно, если надо оставить всё как есть, за исключением каких-то методов.

В остальном всё основано на том, что в методе getDelayed реализация токена cas есть, его я и использую, чтобы заткнуть эту дыру в функциональности. Работает всё так же как в ПХП 5.6, за исключением того, что в методе getMulti нет реализации последнего параметра — флага, вместо этого всё работает так, как будто он установлен, это ничему не мешает.
8 комментариев
14 июля 2016 10:00

🐘 «Синхронная реплика» PostgreSQL

Я в последнее время был очень сильно занят — мы переводили одну из наших крупных инсталляций документооборота на «Постгрес» (правда перевод самой крупной впереди, но у меня чувство, что мы будем ждать следующие версии).

Много любопытного я узнал об этой СУБД, возможно когда-нибудь напишу, если не забудется, но самое примечательное следующее. На «Оракле» у нас, естественно, был кластер, это очень удобно программисту — этакий «чёрный ящик», знай кидай туда запросы, оно само разрулит (на самом деле, это типичная «дырявая абстракция», но чаще всего напрягаться не надо).

На «Постгресе» мы, конечно, захотели аналога и, казалось, нашли его — pgpool-II, который разделяет запросы на пишущие и читающие, которые потом распределяются им на мастер и синхронные реплики.

Наши нагрузочные испытания показали, что на пиковых нагрузках синхронные реплики никакие не синхронные, оказалось, что «синхронность» реплики только в том она говорит мастеру «я всё приняла», когда данные попали на диск и именно в этот момент.

Когда нагрузка близка к пиковой, данные физически на диске есть, а логически они ещё не считываются. То есть это скорее пригодно для того, чтобы в случае смерти мастера быстро поменять его на реплику, чем для схемы с распределением нагрузки.

Это будет исправлено в будущей 9.6, а пока живём с тем, что есть.
6 комментариев
31 марта 2016 14:11

🐘 Подготовленные планы в PostgreSQL

Кто-то меня спрашивал о выгоде преподготовленных планов в «Постгресе». Наши испытания показывают, что выигрыш порядка 10—15%, что очень немало. И я уже рассказывал, что придумал рецепт как делить их в условиях «умирающего» ПХП.

Но вот какая неприятность — при подключении любого балансировщика нагрузки, совершенно неочевидно куда улетает ваш план и таблица в приложении не помогает — она единая, а серверов может быть несколько, у каждого свои планы подготовленные. Если мы начнём подготавливать его заново, а он уже есть, получим ошибку, что план уже существует.

Какой выход? Краткий ответ: пока никакой.

Самый очевидный — игнорировать такие ошибки. К сожалению, он не подойдёт — если ошибка произойдёт в транзакции, «Постгрес» её просто откатит. Второй выход — не использовать подготовленные планы. Я пока нашёл третий — мы используем планы только если уверены, что они пойдут на мастер — это запросы на изменение чего-либо.

С другой стороны у меня появилась идея — добавить в эскуэль конструкцию PREPARE IF NOT EXISTS, ребята из, с которыми я обсуждал эту идею, PostgresPro уже сделали несколько версий патча.

Основа идеи — всегда слать запрос на компиляцию плана, но если он уже был скомпилирован, ничего не делать. Мы его уже погоняли (оттуда и цифры первого абзаца), но на этом пути больше трудностей, чем себе можно представить — в частности, надо патчить ещё и продукты для балансировки и расширять его клиентский протокол.

Очень надеюсь, что патч доведут до ума и мы скоро сможем его использовать.
19 комментариев
27 марта 2016 20:04

🐘 «Рекурсивные» запросы в PostgreSQL

Одна из главных бед «Постгреса» — бедные (по сравнению с «Ораклом») «рекурсивные» запросы. Подробнее об этом как-нибудь в другой раз, а сейчас расскажу про частный случай, который удалось побороть с большим трудом и найденное решение, признаться, мне совсем не нравится.

Если вы знаете рецепт лучше, поделитесь, пожалуйста.

Как я уже рассказывал, поскольку продукт у нас мигрирует с «Оракла» на «Постгрес», мы сейчас живём сразу на двух базах и некоторые виды запросов строят унифицированные билдеры.

Есть такой и для «рекурсивных» запросов. Нередко «рекурсивный» запрос приходится строить, выбирая не из таблицы, а из подзапроса. Наш билдер был устроен таким образом, что подобный запрос он строил по следующему образцу:
WITH RECURSIVE prior AS (
	WITH virtual AS (
		-- тут у нас подзапрос
	)
	SELECT … FROM virtual WHERE …некий критерий…
	UNION ALL
	SELECT … FROM virtual INNER JOIN prior …критерий соединения…
)
SELECT … FROM prior…
Ну вот что-то такое. Оказалось, конструкция WITH является барьером для постгреского оптимизатора — он не может заглянуть за него и планы строит отдельно — для запроса внутри WITH и того, что снаружи. Разумеет это дико неэффективно. Например, если внутри соединение со слабыми ограничениями (сильные наложатся снаружи — в «рекурсивном» запросе), то внутренний запрос может выбрать гигантское количество данных, что у нас и происходило в нескольких местах.

Эффективнее оказалось убрать внутренний WITH и повторить запрос дважды — в выборе первой строки и внутреннем соединении. Но беда в том, что билдер так сделать не может, а чтобы его научить, нужно было написать парсер запросов — так как критерии соединения должен содержать правильные алиасы. Оборачивание же части запроса в подзапрос тоже даром не проходит — стоимость запроса вырастает.

Я перебрал несколько решений, которые пришли мне в голову и остановился на следующем: в данный момент билдер создаёт временную «вьюху» с определённым именем, которое указывается в качестве источника запроса. Выглядит это так:
CREATE OR REPLACE TEMP VIEW некоеимя AS (
	-- тут у нас подзапрос
);
WITH RECURSIVE prior AS (
	SELECT … FROM некоеимя WHERE …некий критерий…
	UNION ALL
	SELECT … FROM некоеимя INNER JOIN prior …критерий соединения…
)
SELECT … FROM prior…
Выходит достаточно эффективно, но смущают две вещи: во-первых, всё это выглядит очень неизящно, во-вторых, для «вьюхи» нельзя подготовить план — все параметры приходится вставлять в запрос, так что максимальная производительность, естественно, не достигается.
Комментировать
20 марта 2016 20:09

👁 Глаз следящий

Глаз, который следит на мышью (18.81КиБ)
Глаз, следящий за мышью в консоли

Обновилась до версии 2.9 моя любимая программа-терминал iTerm2. Изучая новые возможности, обнаружил нечто неожиданное — теперь в консоль можно выводить обычные графические изображения.

Протокол довольно простой:
ESC ] 1337 ; File = [необязательные параметры] : изображение в формате base64 ^G
Решил немного с ним побаловаться, результат на скриншоте — небольшая программа на «баше» — глаз, который следит за указателем мыши.

Пришлось разобраться с тем как вообще получают координаты мыши в консоли, плюс вспомнить школьную геометрию. Синусы, косинусы, вот это всё, неявно вычисляются через awk и используются для определения где нужно рисовать зрачок.

Чем дальше курсор находится от глаза, тем больше событий мыши получает консоль во время перемещений по окружности вокруг него. Из-за этого образуется некая инерционность слежения, которую я стал было корректировать, но потом убрал этот код — инерция придаёт какое-то интересное подобие жизни.

Для запуска требуется iTerm2 2.9 и выше и Imagemagick.
4 комментария
5 марта 2016 19:13

🐘 PostgreSQL, PHP и подготовленные запросы

Одно из отличий «Постгреса» от «Оракла» — подготовленные планы запросов лежат не в разделяемом ресурсе, а в неком хранилище в рамках одного соединения. Программист, в рамках каждого соединения, должен подготовить их оператором PREPARE, в который передаётся выбранный идентификатор запроса и сам запрос, а потом выполнить его при помощи оператора EXECUTE, используя в качестве параметра переданный при подготовке идентификатор и значения параметров.

Польза подготовленных запросов в том, что можно единожды (за время жизни соединения, напоминаю) подготовить запрос, то есть попросить «Постгрес» выполнить его компиляцию в стандартное представление и оптимизацию, а после многократно его использовать, что очевидным образом поднимает производительность приложения.

Схема работы тут очень простая: вычисляем от запроса хеш, ищем его в специальном массиве, если не находим, подготавливаем запрос, используя хеш в качестве идентификатора, после чего хеш добавляем в специальный массив. После чего выполняем подготовленный запрос.

Если план запроса больше не нужен, его можно удалить по идентификатору оператором DEALLOCATE, если же в качестве параметра передать ключевое слово ALL, то будут уничтожены все подготовленные в этом соединении планы. С закрытием соединения, планы так же исчезают.

Теме работы «Постргеса» с ПХП удивительно мало посвящено в руководстве к языку, так что пришлось произвести ряд самостоятельных исследований. Основной вопрос, на который я хотел для себя ответить — есть ли какая-то долгосрочная польза от подготовленных запросов в разрезе того, что обычная модель работы с ПХП — полная смерть скрипта после обработки запроса от клиента.

Оказалось, что это вполне возможно. В ПХП есть «постоянные соединения» — обрабатывающий процесс интерпретатора держит открытым соединение с базой, передавая его новому скрипту, это уменьшает затраты, так как стадия установки соединения и авторизации выполняется только в первый раз.

С открытым соединением в скрипт попадают и подготовленные запросы из предыдущего сеанса, остаётся только как-то получить их имена, но с этим в «Постгресе» проблем нет — они могут быть получены из специальной таблицы.

Код всего описанного выглядит вот так, я его упростил и переписал процедурно:
// открываем постоянное соединение с базой
$con = pg_pconnect($connection_string);

// загружаем подготовленные запросы
$res = pg_query("SELECT name FROM pg_prepared_statements");
$prepared = array_fill_keys(pg_fetch_all_columns($res), true);
pg_free_result($res);

// хеш от запроса, tiger — быстрый алгоритм, я люблю его использовать
$hash = base64_encode(hash('tiger160,3', $sql, true));

// смотрим — был ли уже подготовлен такой запрос
if (!isset($prepared[$hash])) {
	$prepared[$hash] = true;
	pg_prepare($con, $hash, $sql);
}

// выполняем запрос
$res = pg_execute($con, $hash, $params);
Общая идея, думаю, понятна из кода. Пока для меня остаётся открытым вопрос «просачиваются» ли в переданное соединение незакрытые транзакции или временные таблицы (предыдущий его владелец, например, мог умереть из-за нехватки памяти), эксперименты я ещё не проводил, но, думаю, да.

Надо заметить, что модуль «Постгреса» в ПХП в каждое соединение, перед его передачей в приложение, посылает команду RESET ALL, но она, насколько я понял из руководства, лишь сбрасывает различные конфигурационные переметры времени выполнения на значения по-умолчанию и не трогает транзакции и всё остальное (более того, она сама транзакционна).
7 комментариев
29 февраля 2016 20:29