О-о-очень большой JOIN

Добавить оперативки - не вариант?

union попробуй, вдруг прокатит.

Использовать что угодно иное, более подходящее (Spark?) — вариант. В т.ч. и запихнуть все в память.

Только вот до моего начальника не доходит.

Так union конкатенирует строчки, а мне надо столбцы.

UPDATE же работает за квадратичную (!) асимптотику

Если я правильно понял проблему…
Эту таблицу создаёшь с индексами? А если сначала влить в таблицу всю инфу, а уже потом создать индексы? Когда вставляешь или обновляешь строку в таблицу то пересчитываются все затронутые индексы, если вставлять 100 строк (во всяком случае если по запросу на строку) то индекс будет пересчитан 100 раз. С миллионами строк это становится грустно. Поэтому при массовом INSERT/UPDATE бывает смысле отключать индексы и потом создавать их заново.

Да, индексы и их обновление могли бы объяснить многие вещи. Но нет, я их не создаю.

Если кому интересно: Greenplum выдает вот такой вот Execution Plan. То есть оно по одной строчке за раз вытаскивает, что уже слоупочно. Но самое смешное в том, что этот подзапрос выполняется не за константу (мерил при различном числе строк), а за линию или типа того. Это объясняет квадрат.

На эксплэйне большого джойне Greenplum и вовсе повисает.

Update (slice0; segments: 4)  (rows=1434 width=18)
  ->  Explicit Redistribute Motion 4:4  (slice21; segments: 4)  (cost=0.00..4209681.44 rows=1434 width=18)
        ->  Seq Scan on test__training__scoretable  (cost=0.00..4209681.44 rows=1434 width=18)
              SubPlan 20
                ->  Result  (cost=36.71..36.72 rows=1 width=8)
                      Filter: test__training_dum19.id = $0
                      ->  Materialize  (cost=36.71..36.72 rows=1 width=8)
                            ->  Broadcast Motion 4:4  (slice20; segments: 4)  (cost=0.00..36.71 rows=1 width=8)
                                  ->  Seq Scan on test__training_dum19  (cost=0.00..36.71 rows=1 width=8)
...
...
...
              SubPlan 1
                ->  Result  (cost=36.71..36.72 rows=1 width=8)
                      Filter: test__training_dum0.id = $0
                      ->  Materialize  (cost=36.71..36.72 rows=1 width=8)
                            ->  Broadcast Motion 4:4  (slice1; segments: 4)  (cost=0.00..36.71 rows=1 width=8)
                                  ->  Seq Scan on test__training_dum0  (cost=0.00..36.71 rows=1 width=8)

greenplum это база с колоночным хранением, она не предназначена для абдейтов. покажи explain analyze select'а из CTAS work_mem какой?

Денормализуй в одну траблицу все и храни в какой-нибудь молодежной кассандре или просто в одной таблице в постгресе.

JOIN по всем этим дофига таблицам

Можно разбить процесс на INSERT INTO TEMP t1 SELECT ... FROM a1 join a2 on ...; INSERT INTO TEMP t2 SELECT ... FROM t1 join a3 on ...; ...

Ну и временные таблицы дропать как только они дальше не нужны. Должно помочь с памятью.

В общем, забейте.

Я отказался от объединения пятидесяти таблиц в пользу создания сразу нужной таблицы, т.к. функция предсказания по дереву классификации выражается простым набором if-иков (ну или CASE WHEN ... в случае SQL), и, избавившись от джойнов и апдейтов, получил космический выигрыш по времени и памяти.

Всем спасибо :)

Да, greenplum поддерживает колоночное хранение. Здорово. Но каким запросом заставить объединить эти дохрена колонок я так и не понял. JOIN как по пятидесяти, так и по двадцати таблицам вешает оптимайзер запросов намертво, а update это заведомо ущербное решение.

В теории при колоночном хранении объединение столбцов — это очень дешевая операция, а на деле Pivotal'ская документация крайне убогая, и я не нашел сходу таких примеров.

Получаем квадратичную асимптотику по количеству столбцов, что уже крайне плохо.