по одной таблице с выражением
WHERE id = ANY($1::text[])
Поле id - индексировано btree.
Если в параметре $1 будет 11 элементов - идет index scan, который происходит "мгновенно". А если в параметре $1 - чуть больше элементов - 17, то уже происходит seq scan, который выполняется несколько секунд - во много раз дольше.
Что можно с этим сделать?
Можно ли как-то объяснить постгрессу, что 17 - это ненамного больше, чем 11 и можно тоже искать с помощью индекса... или как вообще такое исправлять?
Как раз с помощью tuning, Вы не поверите. ;) Но, первым делом: https://t.me/pgsql/476688
попробуй вначале поставить set random_page_cost to 1.1
Можно еще попробовать set enable_hashjoin to 'off';
Извините, я новичок в задавании вопросов по постгрессу, я не совсем понял, что по ссылке :) Нужно выложить план выполнения?
а этот параметр влияет на запросы по одной таблице? (в запрос JOIN'ов нет вообще)
any это то же join
если мы используем ANY по массиву, постгресс его внутренне превращает в "табличку"?
Нужно прочитать сообщение (по ссылке) и выложить всё, что там написано. Либо попробовать воспользоваться script (который делает то же самое, по идее), и выложить результат.
\d таблицы - это ее DDL скрипт?
Посмотри плана запроса
Это результат выполнения \d+ таблица в psql (полученные неведомо чем "DDL скрипты" иногда не содержат и половины этой информации / вообще теряют индексы и т.п.).
Спасибо, я начинаю понимать. А share_plan.sql - это SQL-скрипт, который я могу запустить у себя, и он соберет всё, что нужно? (я сначала подумал, что это часть какого-то прежнего обсуждения)
Да, идея такая (см. комментарии внутри о том, как им пользоваться).
Обсуждают сегодня