Question

当我连接许多表以汇总结果时，我遇到以下问题：

重复记录，其强度取决于联接表中的多样性
性能低下，这是解释分析揭示的最消耗内存的任务

我的问题很简单：我想告诉PostgreSQL通过逐步执行select命令，使某些选择标准为静态而不是动态，从而在某个时候停止动态查询。

必须完成的工作最好描述如下：

创建一个新表，在其中定义最基本的第一级连接
保存这些“静态”结果
join进入下一个级别的联接，并忽略之前步骤中发生的与下一个联接不再相关的选择标准
重复这些步骤，直到应用所有联接

但是，我不想创建单独的表。我只想通过一个查询就可以实现这一目标。

真的有太多要求吗？我想例如通过子查询来告诉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

PostgreSQL多个联接和子查询

0 个答案: