Добрый день.

Имеется огромная таблица.

Требуется выбрать данные из этой таблицы, связав ее с более мелкой.



При JOIN в плане вложенные циклы.



Возможно ли как-то от них избавиться?

Ну и как можно ускорить данный запрос?

hash join в память не поместится наверное....

Ишу информацию, пока ничего не нашел, как ускорить

MelkijУткъ,

начните с вопроса зачем вам порядка полутриллона записей в результате одного запроса. Что с ними делать дальше?

результат запроса вставляется в новую таблицу.

Maxim BogukУткъНу и как можно ускорить данный запрос?

hash join в память не поместится наверное....

1)показать explain (analyze, costs, buffers, timing) Этого запроса чтобы увидеть реальные цифры

2)попробовать сделать
set work_mem to '8GB';
explain Этого же запроса

3) mt(guid) индекс есть?

Особо не увидев итоги этих 3 попрыток - ничего не посоветуешь.


PS: попробовать на 11 версии сделать (хотя под такой план и 9.6 хватит) поставив достаточное количество параллельных обработчиков.


explain analyze показать невозможно, т.к. запрос выполняется бесконечно долгое клоичество времени.

set work_mem to '8GB' уже сдалал, explain такой же.

индекс есть.


Версия 9.4

Leonid KudryavtsevТеоретически (сам работаю с Oracle), добавив колонки в индекс, можно избежать обращения ко второй таблице. Т.е index scan заменить на https://www.postgresql.org/docs/10/indexes-index-only-scans.html

Как это должно выглядить в плане PostgreSQL на память не помню.


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

Как временное решение добавил лимит и проверку на существующие записи:


INSERT INTO all_table
select mt.guid, bt.data
from big_table bt
join my_table mt on mt.guid = bt.id
WHERE guid NOT IN (select guid FROM all_table)
LIMIT 10000



При определенном количестве LIMIT вложеные циклы превращаются в хэш джоин.



Но это решение как-то кустарно выглядит

Есть ли еще какие-нить варианты?