1с как посмотреть план запроса

Описание и установка внешней обработки «Консоль запросов» для управляемого приложения

Инструмент «Консоль запросов» предназначена для отладки и просмотра результатов выполнения запросов в режиме 1С:Предприятие . Данная обработка предназначена в основном для разработчиков конфигураций и специалистов по внедрению. Данный инструмент можно использовать только в управляемом режиме. Если работа происходит в обычном режиме, то необходимо использовать «Консоль запросов» для 1C:Предприятия 8.1.

При разработке запросов в конфигураторе, как правило, требуется проводить отладку запроса на реальных данных. Данный инструмент позволяет вести разработку запроса (или пакета запросов) параллельно с просмотром результата. При работе с инструментом в толстом клиенте можно воспользоваться конструктором запросов, как и при работе в конфигураторе. Возможности по анализу результата запроса включают:

• вывод данных временных таблиц;
• замер времени выполнения запроса и числа строк;
• подсветку указанных ячеек в результате запроса;
• интерактивное сравнение двух результатов запроса (только в толстом клиенте);
• вывод результата запроса в новом окне;
• вывод плана выполнения запроса, а также SQL-текст запроса, сформированного в СУБД. Для СУБД Microsoft SQL Server план выполнения выводится в виде дерева, а для остальных СУБД – в текстовом формате технологического журнала. Для упрощения анализа запросов также предусмотрено два режима отображения текстов запросов: с именами таблиц и колонок СУБД или с именами объектов метаданных и реквизитов конфигурации (только в обработке для «1С:Предприятие» версии 8.3).

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

ВЫ МОЖЕТЕ ПРЯМО СЕЙЧАС УСТАНОВИТЬ ФАЙЛЫ ОТЧЕТОВ И ОБРАБОТОК
НА ЖЕСТКИЙ ДИСК ВАШЕГО КОМПЬЮТЕРА

Обработка КонсольЗапросов.epf для запуска в «1С:Предприятии» версии 8.2 находится в каталоге \1CITS\EXE\ExtReps\Unireps82\RequestConsoleManaged\

Обработка КонсольЗапросов.epf для запуска в «1С:Предприятии» версии 8.3 находится в каталоге \1CITS\EXE\ExtReps\Unireps83\RequestConsoleManaged\

Методика расследования проблем производительности на уровне работы СУБД PostgreSQL

Соотношение суммарного времени DBPOSTGRS к CALL показывает объем времени, занимаемого запросами, в общем времени вызовов.
Если доля превышает примерно 50%, то это повод разбираться со скоростью выполнения запросов.

Технологический журнал

Для того, чтобы получить запрос и его план, необходимо настроить сбор технологического журнала. Пример настройки:

ВНИМАНИЕ! Данный журнал может занимать значительный объем места на диске.

Настройку нельзя использовать на продуктивных серверах.

Только на серверах тестирования или разработки.

Чтобы получить план запроса, необходимо выполнить запрос непосредственно на сервере PostgreSQL с командой EXPLAIN .

Надо учитывать, что платформа «1С:Предприятие» устанавливает собственные параметры соединения с PostgreSQL. Их также необходимо установить перед выполнением запроса.

Рекомендуется создать файл с необходимыми командами и текстами запросов. Затем выполнить его из командной строки, перенаправив вывод в файл на диске.

Например, есть событие DBPOSTGRS из технологического журнала:

38:31.223006-1,DBPOSTGRS,5,process=rphost,p:processName=DATABASE. SessionID=2. dbpid=11988,Sql ,RowsAffected=1,Result=PGRES_TUPLES_OK,Context='Форма.Вызов : ВыполнитьЗапросСервер…

Создать файл с запросом:

$ vim query.sql

/* Параметры соединения платформы */ SET client_min_messages=error; SET lc_messages to 'en_US.UTF-8'; SET enable_mergejoin = off; SET escape_string_warning = off; SET cpu_operator_cost = 0.001; set client_encoding = 'utf8'; SET lock_timeout = 20000; EXPLAIN ANALYZE VERBOSE -- Получение актуального плана запроса SELECT T1._IDRRef, T1._Number, T1._Date_Time, T1._Fld30743RRef FROM _Document1337 T1 WHERE ((T1._Fld2830 = CAST(0 AS NUMERIC))) AND (T1._IDRRef = '\\200\\310p\\213\\315U\\034~\\021\\347\\025\\340@\\243\\3650'::bytea)

$ psql -U postgres --dbname=DATABASE --file=query.sql > query.sqlplan

Будет получен актуальный план запроса, идентичный платформенному.

$ cat query.sqlplan

Index Scan using _document1337_s_hpk on public._document1337 t1 (cost=0.06..8.07 rows=1 width=69) (actual time=0.011..0.011 rows=0 loops=1) Output: _idrref, _number, _date_time, _fld30743rref Index Cond: ((t1._fld2830 = '0'::numeric) AND (t1._idrref = '\x5c3230305c333130705c3231335c333135555c3033347e5c3032315c3334375c3032355c333430405c3234335c33363530'::bytea)) Planning Time: 2.585 ms Execution Time: 0.069 ms (5 rows)

Сложности возникают, когда исследуемый запрос использует временные таблицы. Тогда, необходимо собрать все запросы, которые заполняют эти таблицы (вверх по журналу от исследуемого запроса).

$ vim query.sql

SET client_min_messages=error; SET lc_messages to 'en_US.UTF-8'; SET enable_mergejoin = off; SET escape_string_warning = off; SET cpu_operator_cost = 0.001; set client_encoding = 'utf8'; SET lock_timeout = 20000; -- запрос использует временную таблицу, необходимо ее создать и заполнить перед его выполнением drop table if exists tt7 cascade; create temporary table tt7 (_Q_000_F_000RRef bytea ) without oids; drop index if exists tmpind_0; create index tmpind_0 on pg_temp.tt7(_Q_000_F_000RRef); INSERT INTO pg_temp.tt7 (_Q_000_F_000RRef) SELECT T1._IDRRef FROM _Document1017 T1 WHERE (T1._Fld2830 = CAST(0 AS NUMERIC)) ; ANALYZE pg_temp.tt7; EXPLAIN ANALYZE VERBOSE -- Получение актуального плана запроса SELECT (T1._Fld30691_TYPE || T1._Fld30691_RTRef), T1._IDRRef FROM _Document1337 T1 INNER JOIN pg_temp.tt7 T2 -- временная таблица ON ('\\010'::bytea = T1._Fld30691_TYPE AND '\\000\\000\\003\\371'::bytea = T1._Fld30691_RTRef AND T2._Q_000_F_000RRef = T1._Fld30691_RRRef) WHERE ((T1._Fld2830 = CAST(0 AS NUMERIC))) AND ((((T1._Fld30691_TYPE || T1._Fld30691_RTRef) <> '\\010\\000\\000\\004\\021'::bytea)))

Чтобы не собирать всю цепочку запросов вручную можно воспользоваться скриптом на языке 1С-Исполнитель getPGQueryWithTempTables.sbsl. После выполнения скрипт создаст файл (или выведет информацию в консоль), где соберет всю цепочку временных таблиц, необходимых для выполнения запроса.

Выгрузка данных для воспроизведения проблемы

Выгрузка только необходимых данных

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

Передача всей базы данных затруднительна или невозможна.

Можно выгрузить только требуемые таблицы. Например, сам запрос и все временные таблицы строятся из таблиц _AccumRg1, _Reference2, _Reference3.

$ pg_dump -h server -U postgres -Fp -b -v -t _AccumRg1 -t _Reference2 -t _Reference3 -d ИМЯБАЗЫ -f /tmp/tables.backup

Однако, если цепочка временных таблиц слишком большая, или текст запроса содержит большое число таблиц, то проще получить их список с помощью скрипта. Для этого, необходимо взять файл с текстом «плохого» запроса и подготовкой всех временных таблиц, для его исполнения. А затем, выполнить скрипт:

$ cat bad_query.sql | grep -oP "(^|\s)_[a-zA-Z]+[0-9]+(_[a-zA-Z0-9]+)?" | grep -vP '^\s+_Fld.*' | grep -vP "_LineNo[0-9]+" | sort | uniq | tr -s '\n' '$' | sed 's/ //g' | sed 's/$$//' | sed 's/\$/ -t /g' | sed 's/\$$//g' | xargs -i echo pg_dump -h server -U postgres -Fp -O -t '<>' -f tables.backup [имя_базы]

Скрипт выведет текст команды pg_dump, для получения только необходимых данных.

Если, для сбора текста запроса, пользоваться скриптом getPGQueryWithTempTables.sbsl, то текст команды pg_dump будет в конце сформированного файла (или вывода консоли).

Для того, чтобы загрузить выгруженные таблицы в новую базу, необходимо создать новую базу на postgres с помощью 1С-Предприятия. В противном случае, будет ошибка при восстановлении таблиц из бэкапа.

$ /opt/1cv8/e2k/8.3.22.1851/1cv8 CREATEINFOBASE Srvr=server\;Ref=ИМЯБАЗЫ\;SchJobDn=Y\;SQLSrvr=СЕРВЕРБД\;DBMS=PostgreSQL\;DB=ИМЯБАЗЫ\;DBUID=postgres\;DBPwd=postgres\;CrSQLDB=Y\; $ psql -h server -U postgres -d ИМЯБАЗЫ -1 -f /tmp/tables.backup -v ON_ERROR_STOP=1

«Легкая» копия

Если необходимо выгрузить базу данных 1С:Предприятия, которая содержит:

• полную структуру таблиц (без данных)
• конфигурацию
• часть таблиц с данными

То необходимо сначала выгрузить схему данных:

$ pg_dump -h server -U postgres --schema-only --dbname=ИМЯБАЗЫ --format=p > schema.sql

Затем, выгрузить данные необходимых таблиц.

$ pg_dump -h server -U postgres --format=p -b --dbname=ИМЯБАЗЫ --clean --if-exists -t _YearOffset -t Config -t ConfigCAS -t ConfigCASSave -t ConfigSave -t DBSchema -t DepotFiles -t Files -t IBVersion -t Params -t SchemaStorage | sed '/^users[.]usr/d' > data.sql

Восстановление базы выполняется в два шага:

$ psql -h server -U postgres --dbname=ИМЯБАЗЫ < schema.sql

$ psql -h server -U postgres --dbname=ИМЯБАЗЫ  data.sql

Если необходимо выгрузить полностью базу в простом формате, не разбивая на схему и данные, то это можно сделать так:

$ pg_dump -h server -U postgres -d ИМЯБАЗЫ-f database.sql -Fp

Восстановление базы выполняется в один шаг:

$ psql -U postgres -h server -d ИМЯБАЗЫ -f database.sql

Иногда бывает полезным выполнить загрузку в одной транзакции и с контролем наличия ошибок. Тогда будет остановка при первой ошибке:

$ psql -U postgres -h server -d ИМЯБАЗЫ -1 -f database.sql -v ON_ERROR_STOP=1

Журнал PostgreSQL

Запросы можно собирать непосредственно в журнале PosgreSQL.

$ psql
ALTER SYSTEM SET lc_messages = 'C'; -- все сообщения на английском языке
ALTER SYSTEM SET logging_collector = on; -- потребуется перезапуск сервера
ALTER SYSTEM SET log_directory = 'log';
ALTER SYSTEM SET log_min_duration_statement = 0; -- 0-все запросы. ВНИМАНИЕ. Сбор всех запросов может ухудшить производительность при высокой нагрузке.
ALTER SYSTEM SET log_duration = on;

$ перезапуск кластера любым способом (pg_ctl / pg_ctlcluster / systemd / service / . )

После этого в каталоге кластера, в папке «log», появится текстовый файл, который будет содержать в себе запросы PostgreSQL.

Преобразование журнала PostgreSQL к однострочному формату (каждое событие в одной строке):

$ cat postgresql.log | awk -vORS= '"$0;>'

Планы запросов в журнале PostgreSQL

Бывает, необходимо получать планы запросов в логе postgres. Например, при вставке во временную таблицу из таблицы значений, используется конструкция COPY … FROM STDIN.
Данные, которые вставляются во временную таблицу, нигде не логируются. Поэтому, сбор цепочки запросов по технологическому журналу не даст эффекта.

$ psql

Получить значение настройки shared_preload_libraries .

SELECT current_setting('shared_preload_libraries');

Дописать модуль auto_explain (потребуется перезапуска кластера).

ALTER SYSTEM SET shared_preload_libraries = '', '',…, 'auto_explain';

$ psql

Настройки модуля auto_explain

ALTER SYSTEM SET auto_explain.log_min_duration = '10s'; -- записывать в лог план для запросов >= 10 сек. 
ALTER SYSTEM SET auto_explain.log_analyze = true; 
SELECT pg_reload_conf(); -- применение настроек

ВНИМАНИЕ! Автоматическое построение планов запросов снижает производительность системы.
Поэтому необходимо задавать параметр auto_explain.log_min_duration, получая планы только длительных запросов.

Отладочная информация в журнале PostgreSQL

Для получения более детальной информации о работе PostgreSQL можно включить сбор отладочных логов.

$ psql 
ALTER SYSTEM SET log_min_messages = 'debug2'; -- debug1. debug5 
SELECT pg_reload_conf(); -- применение настроек

ВНИМАНИЕ! Включение данного журнала будет занимать значительный объем и может привести к замедлению СУБД.

Статистика исполнения запросов

Для расследования проблем может понадобится статистика по потреблению ресурсов запросами:

• процессор
• диск
• буферный пул
• количество исполнений
• и т.д.

Для этого необходимо подключить модуль pg_stat_statements.

$ psql 
ALTER SYSTEM SET shared_preload_libraries = …, 'auto_explain', 'pg_stat_statements';

$ psql ALTER SYSTEM SET pg_stat_statements.max = 10000; ALTER SYSTEM SET pg_stat_statements.track = 'all'; SELECT pg_reload_conf(); -- применение настроек \с ИМЯ _БАЗЫ CREATE EXTENSION pg_stat_statements; SELECT pg_stat_statements_reset(); -- для сброса накопленной статистики..

Примеры полезных запросов

-- Нагрузка, создаваемая запросами SELECT pg_database.datname AS Database, pg_stat_statements.query AS Query, pg_stat_statements.calls AS ExecutionCount, pg_stat_statements.total_time ExecutionTime, pg_stat_statements.shared_blks_read + pg_stat_statements.shared_blks_written AS Memory, pg_stat_statements.local_blks_read + pg_stat_statements.local_blks_written AS IO, pg_stat_statements.temp_blks_read + pg_stat_statements.temp_blks_written AS Temp FROM pg_stat_statements AS pg_stat_statements INNER JOIN pg_database AS pg_database ON pg_database.oid = pg_stat_statements.dbid ORDER BY ExecutionTime DESC

-- Процент попадания в кэш SELECT round(100 * sum(blks_hit) / sum(blks_hit + blks_read), 3) as cache_hit_ratio FROM pg_stat_database;

-- Размер таблиц и индексов SELECT t.tablename, indexname, c.reltuples::integer AS num_rows, pg_size_pretty(pg_relation_size(quote_ident(t.tablename)::text)) AS table_size, pg_size_pretty(pg_relation_size(quote_ident(indexrelname)::text)) AS index_size, CASE WHEN x.is_unique = 1 THEN 'Y' ELSE 'N' END AS UNIQUE, idx_scan AS number_of_scans, idx_tup_read AS tuples_read, idx_tup_fetch AS tuples_fetched FROM pg_tables t LEFT OUTER JOIN pg_class c ON t.tablename=c.relname LEFT OUTER JOIN (SELECT indrelid, max(CAST(indisunique AS integer)) AS is_unique FROM pg_index GROUP BY indrelid) x ON c.oid = x.indrelid LEFT OUTER JOIN ( SELECT c.relname AS ctablename, ipg.relname AS indexname, x.indnatts AS number_of_columns, idx_scan, idx_tup_read, idx_tup_fetch,indexrelname FROM pg_index x JOIN pg_class c ON c.oid = x.indrelid JOIN pg_class ipg ON ipg.oid = x.indexrelid JOIN pg_stat_all_indexes psai ON x.indexrelid = psai.indexrelid ) AS foo ON t.tablename = foo.ctablename WHERE t.schemaname='public' ORDER BY pg_relation_size(quote_ident(indexrelname)::text) desc;

-- Отсутствие индексов SELECT relname, seq_scan - coalesce(idx_scan, 0) AS too_much_seq, case when seq_scan - coalesce(idx_scan, 0) > 0 THEN 'Нет индекса?' ELSE 'OK' END AS Message, pg_relation_size(relname::regclass) AS rel_size, seq_scan, coalesce(idx_scan, 0) AS idx_scan FROM pg_stat_all_tables WHERE schemaname='public' AND pg_relation_size(relname::regclass)>10000 -- ограничение на размер анализируемых таблиц ORDER BY too_much_seq DESC;

-- Использование буферного КЭШа (необходимо установить расширение pg_buffercache) CREATE EXTENSION pg_buffercache; SELECT 'total', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int)) FROM pg_buffercache UNION SELECT 'dirty', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int)) FROM pg_buffercache WHERE isdirty UNION SELECT 'clear', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int)) FROM pg_buffercache WHERE NOT isdirty UNION SELECT 'used', pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int)) FROM pg_buffercache WHERE reldatabase IS NOT NULL UNION SELECT 'free',pg_size_pretty(count(*) * (SELECT current_setting('block_size')::int)) FROM pg_buffercache WHERE reldatabase IS NULL ;

-- Содержимое буферного пула SELECT c.relname, pg_size_pretty(pg_relation_size(c.oid)) as relation_size, pg_size_pretty(count(b.bufferid) * (SELECT current_setting('block_size')::int)) AS buffered_in_shared_buffers, round(100 * count(b.bufferid) * (SELECT current_setting('block_size')::int) / greatest(1,pg_relation_size(c.oid)),1) as pct_of_relation, round((100 * count(b.bufferid) / greatest(1,(SELECT setting FROM pg_settings WHERE name = 'shared_buffers')::decimal)),2) AS pct_of_shared_buffers FROM pg_class c INNER JOIN pg_buffercache b ON b.relfilenode = c.relfilenode AND b.reldatabase IN (0, (SELECT oid FROM pg_database WHERE datname = current_database())) -- WHERE c.relname = 'products' AND usagecount >= 2 – если нужен отбор по таблице GROUP BY c.oid, c.relname ORDER BY count(b.bufferid) * 8192 DESC LIMIT 10;

Запрос, который выполняется сейчас

Требуется разовая настройка:

$ psql 
ALTER SYSTEM SET track_activity_query_size = 1048576; -- храним тексты запросов размером до 1Мб.

Далее перезапускаем кластер, чтобы настройка применилась.

Теперь можно выполнять запрос:

$ psql SELECT datname, application_name, pid, now() - pg_stat_activity.query_start AS duration, query FROM pg_stat_activity WHERE state = 'active' ORDER BY duration DESC LIMIT 10;

Центр управления производительностью

Для расследования долгих запросов можно воспользоваться конфигурацией «Центр управления производительностью» из «Корпоративного инструментального пакета».

Для этого необходимо подключить исследуемую базу в режиме мониторинга.

Снять замеры и выполнить анализ.

Мониторинг ожиданий PostgreSQL

Если нет конкретного запроса, который приводит к замедлению системы (СУБД в целом работает медленно), то для расследования причин можно воспользоваться сбором статистики по ожиданиям.

Простой скрипт мониторинга текущих ожиданий:

$ vim ./wait_monitor.sh

#!/bin/bash while true do printf "\033c" psql -h server -U postgres -c "select wait_event_type, wait_event, count(*) as count from pg_stat_activity where state='active' group by wait_event_type, wait_event order by 3 desc;" sleep 3 done

$ chmod +x ./wait_monitor.sh

$ ./wait_monitor.sh

Cкрипт можно запустить в отдельном окне терминала и наблюдать в режиме реального времени, статистику по ожиданиям.
Данная статистика приблизительная, т.к. на экран выводится состояние по ожиданиям раз в 3 секунды. Все, что произошло за 3 секунды паузы – теряется.
Но для общей картины происходящего этого достаточно.

Затем необходимо взять ожидание, которое чаще всего находится на самом верху и разобраться в его причинах, воспользовавшись его описанием по ссылке https://www.postgresql.org/docs/current/monitoring-stats.html#WAIT-EVENT-TABLE

Чтобы накапливать статистику по ожиданиям, можно сохранять вывод скрипта в файл.
Для этого скрипт необходимо модифицировать:

$ vim ./wait_monitor_csv.sh

#!/bin/bash while true do psql -h server -U postgres --no-align --csv --tuples-only -c "select now() as timestamp, wait_event_type, wait_event, count(*) as count from pg_stat_activity where state='active' group by wait_event_type, wait_event;" sleep 3 done

$ chmod +x ./wait_monitor_csv.sh

$ ./wait_monitor_csv.sh >> ./wait.log

В файл wait.log будут собраны снимки ожиданий.

Выполнить анализ собранных ожиданий можно с помощью psql.

$ psql 
create temp table waits(timestamp timestamp, wait_event_type varchar(100), wait_event varchar(100), count int); 
COPY pg_temp.waits(timestamp, wait_event_type, wait_event, count) FROM '/home/user/wait.log' DELIMITER ',' CSV; 
SELECT wait_event_type, wait_event, SUM(count) FROM pg_temp.waits GROUP BY wait_event_type, wait_event ORDER BY 3 DESC;

Загруженность оборудования

atop

$ sudo apt install atop

Режим интерактивного мониторинга

$ sudo atop

Cбор данных в файл. 1200 снимков с интервалом 3 секунды (1 час.)

$ sudo atop -w atop.log 3 1200

Если запущена служба atop, то счетчики оборудования снимаются постоянно. См.

$ sudo systemctl status atop 
Loaded: loaded (/lib/systemd/system/atop.service; enabled; vendor preset: enabled) 
. . . . . . . 
CGroup: /system.slice/atop.service 
??6984 /usr/bin/atop -R -w /var/log/atop/atop_20221220 600

600 – это количество секунд между снимком информации о загруженности оборудования.

Частоту снятия счетчиков, службой, можно поменять

$ sudo vim /etc/default/atop

INTERVAl=60

$ sudo systemctl restart atop

Настройки журнала ежедневных счетчиков

$ sudo vim /usr/share/atop/atop.daily

Сбор данных в формате, пригодном для автоматической обработки (раз в секунду, до остановки по Ctrl+C)

$ sudo atop -P CPU,DSK,MEM,NET 1 > atop.csv

Преобразование бинарного файла в данные для автоматической обработки

$ atop -r /var/log/atop/atop_20221221 -P CPU,DSK,MEM,NET > atop.csv

Преобразование бинарного файла в текстовое представление для просмотра

$ atop -r /var/log/atop/atop_20221221 > atop.txt

Для визуализации atop можно написать «парсер», который преобразует собранные данные в формат (например csv).

Затем, загрузить эти данные в любое ПО для построения графиков.

Готовые средства, для просмотра графиков atop, можно найти в интернете по фразе «atop visualization».

nmon

Более продвинутое в визуальном смысле средство мониторинга — nmon.

$ sudo apt install nmon

Режим интерактивного мониторинга

$ sudo nmon

## (нажать C n d t u)

Если запустить в отдельной консоли монитор ожиданий PostgreSQL, то можно оценивать текущее состояние postgres и загрузки сервера.

Cбор данных в файл

$ nmon -f -s 2 -c 600 # 600 снимков с интервалом 2 секунды

Сформированный файл необходимо обработать для загрузки в ПО построения графиков.
Или воспользоваться готовыми средствами, которые можно найти по фразе «nmon visualizer».

Какой запрос нагружает оборудование

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

Найти его в технологическом журнале по полю dbpid.

53:32.515071-125295937,DBPOSTGRS,4,process=rphost,p:processName=erp,OSThread=42008,t:clientID=656,t:applicationName=1CV8C,t:computerName=server,t:connectID=13931,SessionID=190, Usr=Кладовщик документы_ТЦ000018,AppID=1CV8C,DBMS=DBPOSTGRS,DataBase=127.0.0.1\ERP,Trans=0,dbpid=167172,Sql=" SELECT T1._Fld836 FROM _InfoRg835 T1 LEFT OUTER JOIN _Document67 T2 ON T1._Fld847RRef = T2._IDRRef WHERE (T1._Fld839RRef IN ( VALUES('\\257,\\260\\260w\\260\\347SFg\\321\\311\\271E\\225\\026'::bytea), ('\\215\\000\\001\\342cX\\242?B\\237\\321\\355\\002\\242\\210\\237'::bytea), ('\\265\\257\\323\\2650-\\274\\016Dp\\211\\263\\277\\376\\026\\012'::bytea))) AND ((T1._Fld846 < '2022-11-21 00:00:00'::timestamp) OR (T1._Fld847RRef <>'\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000'::bytea) AND (T2._Date_Time IS NULL)) ",RowsAffected=1,Result=PGRES_TUPLES_OK,Context='

Или в логе postgres

2022-12-21 09:53:32.121 MSK [167172] postgres@ERP LOG: duration: 1251.295 ms bind : SELECT T1._Fld836 FROM _InfoRg835 T1 LEFT OUTER JOIN _Document67 T2 ON T1._Fld847RRef = T2._IDRRef WHERE (T1._Fld839RRef IN ( VALUES('\\257,\\260\\260w\\260\\347SFg\\321\\311\\271E\\225\\026'::bytea), ('\\215\\000\\001\\342cX\\242?B\\237\\321\\355\\002\\242\\210\\237'::bytea), ('\\265\\257\\323\\2650-\\274\\016Dp\\211\\263\\277\\376\\026\\012'::bytea))) AND ((T1._Fld846 < '2022-11-21 00:00:00'::timestamp) OR (T1._Fld847RRef <>'\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000'::bytea) AND (T2._Date_Time IS NULL))

Если запрос еще выполняется, то получить его из pg_stat_activity

$ psql 
SELECT datname, application_name, pid, now() - pg_stat_activity.query_start AS duration, query FROM pg_stat_activity WHERE state = 'active' and pid = 167172;
Использование SQL Profiler для поиска и исправления медленных запросов в 1С
Построение плана запроса необходимо, т.к. один и тот же запрос можно получить разными способами:

сканировать таблицу или искать по индексу,
выбору способа соединения таблиц и т.д.

Построение плана запроса в SQL Server занимается так называемый оптимизатор СУБД, который исходя из пришедшего текста запроса, статистики, существующих индексов иограниченного времени (СУБД не может много времени тратить на выбор плана запроса) строит самый оптимальный план запроса, который сможет быстрее всего выполниться и снаименьшими затратами ресурсов.
План запроса можно сравнить с таксистом:

Мы ловим такси и говорим, куда нам нужно ехать, – это был наш запрос.
Дальше таксист начинает в голове строить маршрут, по которому он поедет, чтобы быстрее добраться до места назначения, – это работа оптимизатора СУБД, а выбранный маршрут является планом запроса.
При движении по выбранному маршруту таксист неожиданно оказывается в пробке и вместо того, чтобы быстро добраться до места, целый час в ней простоял – это ошибка оптимизатора СУБД, который построил неоптимальный план запроса (например, статистика была неактуальная).

Поэтому медленно работающий запрос – это медленно работающий план запроса.
Статью целиком читайте в журнале «Системный администратор», №06 за 2016 г. на страницах 38-43.
PDF-версию данного номера можно приобрести в нашем магазине.
1с как посмотреть план запроса
Хочу рассказать о разработке, предназначенной для облегчения написания запросов "без кривизны" 
Поскольку наша команда (gilev.ru) специализируется на повышении производительности, то вопрос автоматизации рутинных операций в нашем деле стал достаточно быстро. Очевидно, что повторяющиеся простые действия не надо делать «руками».
Кто бы что на разных курсах не рассказывал «про чудесные секреты», а основным показателем является количество оптимизированных запросов. Просто и банально.
Другими словами, большая часть проблем производительности 1С лежит в неоптимальных запросах. Даже многие блокировки — лишь следствие избыточного сканирования данных неоптимальными запросами.
Поэтому основная задача оптимизации всегда будет в том числе в оптимизации наиболее используемых запросов. 
Мы написали свою обработку. Не бог весть что, но работу облегчает.
Но как говориться лучше один раз увидеть https://www.youtube.com/watch?v=q9bKv5LwRdk , чем сто раз услышать.
Поэтому отдаем на Ваш суд нашу консоль запросов, которую можно скачать на главной странице http://www.gilev.ru/#ConsoleGilevRu , на текущий момент это версия http://www.gilev.ru/1c/cloud/GilevRu_Console_1_5_1.epf 
Нужно настроить консоль согласно инструкции http://www.gilev.ru/console_setup 
Результат анализа отображается на нашем сервере https://isinka.gilev.ru/QueryAnalyzerService/ 
Важно. Готовы делится бесплатно анализом запросов взамен на Ваш обратный отзыв и рекомендации, а конкретнее: 
• Написать в почту slava@gilev.ru запрос с ссылкой на эту ветку и указать учетную запись в наших сервисах - 10 запросов бесплатно 
• по каждому запросу и обнаруженной рекомендации дать обратную связь нам, насколько ясна рекомендация, помогла ли она - еще 3 запроса бесплатно по каждой обратной связи 
• написать отзыв на своей странице и сообщить нам об этом - 3 месяца безлимита 
• написать отзыв в своем блоге и сообщить нам об этом- 1 месяц безлимита 
• написать отзыв в своей ленте в социальных сетях и сообщить нам об этом- 1 неделя безлимита
Я думаю что на экзамене 1С:Эксперт нашей обработкой Вам пользоваться не разрешат – слишком легко сдавать будет  
А вот на наших курсах http://www.gilev.ru/kurs/ можно все , в том числе убедиться насколько это мощный инструмент ускорения любой информационной системы. 
Уверен, со временем наш подход, реализованный в этой обработке станет новым стандартом в области оптимизации. Спасибо что дочитали до конца! 
Согласовано с Волшебником


Похожие публикации:

Как активировать код в app store
Как выгрузить сделки из битрикс24 в excel
Что с lg channels случилось
Что такое 1с грм