Что означает cost? Почему показывает с интервалом? Привет всем ))

https://www.postgresql.org/docs/current/using-explain.html (И там есть ответы на многие другие подобные вопросы.)

Спасибо Можете подсказать какой из них более производительный?

Чтобы что-то подсказывать по планам, лучше привести https://t.me/pgsql/288632

1. https://explain.depesz.com/s/vbrZ 2. https://explain.depesz.com/s/Ey8v

И Вы не показали ничего из того, о чём я спрашивал. ;( Так что ничего неочевидного тут и не скажешь. А какой практический вопрос, кстати? Зачем Вы сравниваете эти планы?

В одном запросе используется left join lateral в другом запросе with pipeline

Если смотреть на время выполнения то with выполняется чуть быстрее чем lateral join

И не только не показали, но и не ответили ни на один вопрос. Наверное, помощь Вам не нужна. ;(

Вы наверное последнее письмо не видели (может оно пока на модерации). Суть следующая: где-то внутри функций используются запросы с window function. Если написать вот так: SELECT * FROM agreement_totals( tstzrange( '2020-08-01', '2020-08-01', '[]' ) ) WHERE agreement_id = 3472::int AND (o).period_id = 10::int То я получу неверную сумму, потому что использовал (o).period_id.

Хмм... видимо, не видел. Но тогда на Ваш вопрос невозможно ответить — примера-то никто пока не видел. ;) Можете целиком показать?

Ну ясно же сравниваю эти двух способов. Хочу узнать какой из этих вариантов более производительный

Покажите 1) версию PostgreSQL, 2) запрос, 3) \d каждой используемой таблицы, 4) EXPLAIN (ANALYZE, BUFFERS). Если действительно хотите — покажите все 4 (четыре), и именно те, которые указаны в пунктах. ;)

3  пункт не совсем понял

Это метакоманда psql, \d таблица

PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit select property_type, count(*) as amount from pages group by property_type baikal-# \d pages ERROR: column c.relhasoids does not exist LINE 1: ...riggers, c.relrowsecurity, c.relforcerowsecurity, c.relhasoi... Finalize GroupAggregate (cost=551738.73..551739.74 rows=4 width=17) (actual time=334532.077..334532.083 rows=5 loops=1)

> PostgreSQL 12.3 А должен быть уже 12.7 — обновите, это же несложно. > ERROR: column c.relhasoids does not exist И с версией клиента тоже какая-то ерунда — установите актуальную (для v12 или новее). > Finalize GroupAggregate (cost=551738.73..551739.74 rows=4 width=17) (actual time=334532.077..334532.083 rows=5 loops=1) Полный план, а не какие-то куски, естественно!

QUERY PLAN | ---------------------------------------------------------------------------------------------------------------------------------------------------+ Finalize GroupAggregate (cost=551738.73..551739.74 rows=4 width=17) (actual time=334532.077..334532.083 rows=5 loops=1) | Group Key: property_type | Buffers: shared hit=6014 read=176388 | -> Gather Merge (cost=551738.73..551739.66 rows=8 width=17) (actual time=334532.059..335118.492 rows=15 loops=1) | Workers Planned: 2 | Workers Launched: 2 | Buffers: shared hit=12548 read=523344 | -> Sort (cost=550738.71..550738.72 rows=4 width=17) (actual time=333967.542..333967.543 rows=5 loops=3) | Sort Key: property_type | Sort Method: quicksort Memory: 25kB | Worker 0: Sort Method: quicksort Memory: 25kB | Worker 1: Sort Method: quicksort Memory: 25kB | Buffers: shared hit=12548 read=523344 | -> Partial HashAggregate (cost=550738.63..550738.67 rows=4 width=17) (actual time=333967.501..333967.502 rows=5 loops=3) | Group Key: property_type | Buffers: shared hit=12532 read=523344 | -> Parallel Seq Scan on pages (cost=0.00..545784.42 rows=990842 width=9) (actual time=33.668..333048.757 rows=758565 loops=3)| Buffers: shared hit=12532 read=523344 | Planning Time: 0.120 ms | JIT: | Functions: 21 | Options: Inlining true, Optimization true, Expressions true, Deforming true | Timing: Generation 5.497 ms, Inlining 1668.064 ms, Optimization 118.266 ms, Emission 82.387 ms, Total 1874.213 ms | Execution Time: 335120.611 ms |

"Когда же это прекратится, и где же этому конец?" © Ещё раз, если действительно хотите помощи — покажите все 4 (ЧЕТЫРЕ!), и ИМЕННО те, которые указаны в пунктах!

вот в нормальном виде explain analyze https://paste.ofcode.org/XqCeRHbxsyKYq3Gz6BmjZM

спс, нашёл решение CREATE INDEX msg_lower ON messages (lower(id));

Или не нашли, а наблюдаете просто эффект кеширования. Вас же не просто так (уже четыре раза?!) попросили показать план... но дело Ваше, конечно. ;)

> Если действительно хотите — покажите все 4 (четыре), и именно те, которые указаны в пунктах. ;) Когда же это прекратится, и где же этому конец... ;( > explain analyze - 7.000ms Плевать мы хотели Не имеет значения, сколько там ms! Это наименее существенная часть в выводе explain. Нужно всё перечисленное, полностью.

Все версии последние с сайта postgresql (сервер и odbc) SELECT FIELD_1 FROM TABLE_1 WHERE id=123 (самый простой - 1 поле из одной таблицы) Если смотреть в коде if (QR_command_maybe_successful(res) && res->backend_tuples) { SC_set_error(self, STMT_SEQUENCE_ERROR, "The cursor is open.", func); return TRUE; } Что то не удаляется после SQLCancel

analyze verbose целевой таблицы и таблиц с внешними ключами решил проблему, спасибо всем, кто откликнулся

Добрый день! Какая дальнейшая методология ускорения скрипта? Где могу изучить?

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

Фундаментально, спасибо

https://postgrespro.ru/education/courses/QPT

И да, вы вроде сейчас в активной разработке. Я советую сменить postgres на 14. За эту пятилетку в движке создано реально много полезного.

это в планах, я после и там проверки проведу такие же. Просто странно, что Buffers: shared hit вырастает при работе комплекса, и скидывается при перезапуске "ПГ".

Подскажите пожалуйста где можно почитать о том как понимать то что выдаете EXPLAIN(analyze,buffers)

Нетленка

Начать с нашэго закрепа: https://t.me/pgsql/303899