PostgreSQL несколько объединений и подзапросов - PullRequest
Новая
       19

PostgreSQL несколько объединений и подзапросов

0 голосов
/ 01 мая 2019

Когда я объединяю множество таблиц для агрегирования результатов, я сталкиваюсь со следующими проблемами:

  • Дублирующиеся записи, интенсивность которых зависит от разнообразия в объединяемых таблицах

  • Низкая производительность, из которых виды являются наиболее ресурсоемкими задачами, выявленными при анализе объяснения

Мой вопрос очень прост: я хочу сказать PostgreSQL, чтобы запрос не выполнялсядинамически в какой-то момент путем поэтапной установки команды выбора, делая определенные критерии выбора статическими, а не динамическими.

То, что должно быть выполнено, лучше всего описать следующим образом:

  • создать новую таблицу, в которой я определяю самые основные объединения первого уровня

  • сохранить эти "статические" результаты

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

  • повторять этиps, пока не будут применены все объединения

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

Неужели это слишком много, чтобы просить?Я хочу сказать PostgreSQL, например, с подзапросами, что возможности ограничены и что он не должен продолжать беспокоиться о сортировках, а что нет, когда предыдущий подзапрос правильный.

Это примерзапрос: 

select a.report_id, a.object_id, a.statement, b.datapoint_id, dp.aspect_id, dp.entity_identifier_id, dp.period_id, dp.aspect_value_selection_id, dp.effective_value, c.label, r.start_id_pos, r.start_id_neg
from "..statements" a
left join table_data_points b on a.object_id = b.object_id
left join data_point dp on b.datapoint_id = dp.datapoint_id
left join "...labels" c on dp.aspect_id = c.aspect_id and a.statement = c.statement
left join ".relationships" r on a.relationship_set_id = r.relationship_set_id and dp.aspect_id = r.from_id
where a.report_id=1 and c.label is not null

Объяснить анализ: 

Merge Join  (cost=1151055.97..1198086.26 rows=3334642 width=200) (actual time=7295.864..7527.759 rows=178402 loops=1)
  Merge Cond: ((c.aspect_id = dp.aspect_id) AND ((c.statement)::text = (a.statement)::text))
  ->  Sort  (cost=94244.49..96166.99 rows=768997 width=34) (actual time=3772.495..3857.589 rows=381191 loops=1)
        Sort Key: c.aspect_id, c.statement
        Sort Method: quicksort  Memory: 91433kB
        ->  Seq Scan on ...labels c  (cost=0.00..19064.97 rows=768997 width=34) (actual time=0.126..1851.052 rows=768511 loops=1)
              Filter: (label IS NOT NULL)
  ->  Sort  (cost=1056811.07..1057409.25 rows=239275 width=179) (actual time=3523.293..3540.153 rows=178163 loops=1)
        Sort Key: dp.aspect_id, a.statement
        Sort Method: quicksort  Memory: 74kB
        ->  Merge Left Join  (cost=1028295.21..1035433.87 rows=239275 width=179) (actual time=3383.303..3522.908 rows=301 loops=1)
              Merge Cond: ((dp.aspect_id = r.from_id) AND (a.relationship_set_id = r.relationship_set_id))
              ->  Sort  (cost=896234.26..896832.45 rows=239275 width=75) (actual time=134.169..134.253 rows=289 loops=1)
                    Sort Key: dp.aspect_id, a.relationship_set_id
                    Sort Method: quicksort  Memory: 65kB
                    ->  Gather  (cost=1001.14..874857.06 rows=239275 width=75) (actual time=15.204..133.907 rows=289 loops=1)
                          Workers Planned: 1
                          Workers Launched: 1
                          ->  Nested Loop  (cost=1.14..849929.56 rows=140750 width=75) (actual time=0.056..34.625 rows=145 loops=2)
                                ->  Nested Loop  (cost=0.57..25680.40 rows=140750 width=35) (actual time=0.025..33.949 rows=145 loops=2)
                                      ->  Parallel Seq Scan on ..statements a  (cost=0.00..4150.51 rows=4 width=27) (actual time=0.012..33.840 rows=2 loops=2)
                                            Filter: (report_id = 1)
                                            Rows Removed by Filter: 116790
                                      ->  Index Scan using table_data_points_index04 on table_data_points b  (cost=0.57..5337.80 rows=4467 width=16) (actual time=0.010..0.038 rows=72 loops=4)
                                            Index Cond: (object_id = a.object_id)
                                ->  Index Scan using data_point_pkey on data_point dp  (cost=0.57..5.85 rows=1 width=48) (actual time=0.004..0.004 rows=1 loops=289)
                                      Index Cond: (datapoint_id = b.datapoint_id)
              ->  Sort  (cost=132060.85..133822.38 rows=704613 width=128) (actual time=3249.054..3354.045 rows=264922 loops=1)
                    Sort Key: r.from_id, r.relationship_set_id
                    Sort Method: external sort  Disk: 82536kB
                    ->  Seq Scan on .relationships r  (cost=0.00..63620.13 rows=704613 width=128) (actual time=0.059..1005.916 rows=704415 loops=1)
Planning time: 47.995 ms
Execution time: 7565.196 ms
...