Я внимательно не читал это длинное обсуждение, но мне любопытно...

на основании чего были сделаны все эти выводы?

Про то, что параллельных воркеров отрубает при Execute с "maximum number of rows" отличным от FETCH_ALL (в любом смысле) -- в исходнике в общем написано. src/backend/postgres.c: exec_execute_message(const char *portal_name, long max_rows) ... if (max_rows <= 0) max_rows = FETCH_ALL; completed = PortalRun(portal, max_rows, true, /* always top level */ !execute_is_fetch && max_rows == FETCH_ALL, receiver, receiver, &qc); src/backend/pquery.c: PortalRun(Portal portal, long count, bool isTopLevel, bool run_once, DestReceiver *dest, DestReceiver *altdest, QueryCompletion *qc) ... portal->run_once = run_once; ... nprocessed = PortalRunSelect(portal, true, count, dest); ... PortalRunSelect(Portal portal, bool forward, long count, DestReceiver *dest) ... ExecutorRun(queryDesc, direction, (uint64) count, portal->run_once); src/backend/executor/execMain.c: ExecutorRun(QueryDesc *queryDesc, ScanDirection direction, uint64 count, bool execute_once) ... standard_ExecutorRun(queryDesc, direction, count, execute_once); ... standard_ExecutorRun(QueryDesc *queryDesc, ScanDirection direction, uint64 count, bool execute_once) ... ExecutePlan(estate, queryDesc->planstate, queryDesc->plannedstmt->parallelModeNeeded, operation, sendTuples, count, direction, dest, execute_once); ... ExecutePlan(EState *estate, PlanState *planstate, bool use_parallel_mode, CmdType operation, bool sendTuples, uint64 numberTuples, ScanDirection direction, DestReceiver *dest, bool execute_once) ... if (!execute_once) use_parallel_mode = false;

Про этот вывод ясно, спасибо! А что из них передавало не FETCH_ALL в EXECUTE / использовало не simple query protocol?

JDBC (оно испокон века не simple), и галочка в настройках ... IDE кажэтся -- Limit page size to https://t.me/pgsql/322693

Понятно. То, что это происходит, можно было непосредственно увидеть только с помощью auto_explain, наверное.

И да, в JDBC postgresql это, очевидно, будут параметры preferQueryMode extended | extendedForPrepared | extendedCacheEverything | simple The default is extended и defaultRowFetchSize The default is zero, meaning that in ResultSet will be fetch all rows at once.

Меня сейчас дажэ большэ интересует -- откуда у него была разница в pgadmin между explain и запросом. Запрос выполнялся быстро, explain -- медленно. Но я пока думаю, как можно что-то сымитировать.

Возможно, overhead на timing. Кто его знает, какая это OS и т.п.

Как-то очень точно соответствовало по времени.

Соответствовало чему (опять-таки, я всё обсуждение внимательно не читал)?

Запросы с explain, во всех вариантах, соответствовали таймингу JDBC с fetchLimit=500 (притом установка параметра JDBC на тйминг с explain никак не влияла). Там у него на разных данных два запроса было -- один выполнялся 6-8 секунд в быстром случае и 20-22 в медленном. Другой -- 15-20 секунд в быстром случае и 1:15 в медленном.

Да, именно так. У коллег по работе на других компах схожий результат был. И на других запросах был похожий эффект.

Попробуй на большой выборке сделать группировку по индексирусыс полям. Наверное тогда запрос будет быстрее выполняется чем plan explain analiz

Странно, но, опять-таки, кто его знает, что эти клиенты там посылают (в плане протокола). Нужно было сравнить с psql, для начала. А потом посмотреть auto_explain, если есть возможность.

Ну вот мы и выяснили что phpStorm посылает команду в jdbc. Это и влияет на время выполнения. Теперь мы воорожены знаниями, что если использовать jdbc драйвер с лимитом, то запросы могут дольше выполняться.

Я пока только частично понял происходящее — ясно, что использование не FETCH_ALL в EXECUTE отключает parallel_mode. Неясно, почему https://t.me/pgsql/322788

да я вобще до вчерашнего дня и не подозревал о существовании jdbc и о том что IDE через него работает ))))))

Это, безусловно, из-за того, что он не хочет выполнять parallel_mode из-за execute_once. Скорее всего, есть опасение, что если запрос не отработает до конца -- то воркеры обязаны будут подвиснуть до следующего Execute, в котором -- продолжыть предыдущую работу. Но детали и историю этой части я пока что не читал