Эти Postgres подзапроса Subselect InitPlans выполняются параллельно? - PullRequest
Новая
       90

Эти Postgres подзапроса Subselect InitPlans выполняются параллельно?

0 голосов
/ 27 мая 2020

Я пытаюсь понять, как работает Postgres. Прочитав это, https://www.postgresql.org/message-id/4572.1280671706%40sss.pgh.pa.us Эти подзапросы являются подзапросами, потому что они не ссылаются ни на что во внешнем запросе, верно? Итак, если они независимы, означает ли это, что они естественно выполняются одновременно / параллельно?

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

Nested Loop Left Join  (cost=20.40..28.41 rows=1 width=2547) (actual time=0.086..0.087 rows=1 loops=1)
  Join Filter: (load_profiles.project_id = projects.id)
  InitPlan 1 (returns $0)
    ->  Index Scan using index_designs_on_project_id_and_tenant_id on designs  (cost=0.11..4.12 rows=1 width=16) (actual time=0.010..0.013 rows=2 loops=1)
          Index Cond: ((project_id = '10821ae7-2867-46b5-a3ac-6b4cb709f7c0'::uuid) AND (tenant_id = '5189ea23-726f-4115-991d-959d09e3b858'::uuid))
  InitPlan 2 (returns $1)
    ->  Index Scan using index_design_requests_on_project_id_and_tenant_id on design_requests  (cost=0.08..4.09 rows=1 width=16) (actual time=0.006..0.006 rows=0 loops=1)
          Index Cond: ((project_id = '10821ae7-2867-46b5-a3ac-6b4cb709f7c0'::uuid) AND (tenant_id = '5189ea23-726f-4115-991d-959d09e3b858'::uuid))
  InitPlan 3 (returns $2)
    ->  Index Scan using index_ortho_images_on_parent_type_and_parent_id on ortho_images  (cost=0.11..7.90 rows=1 width=16) (actual time=0.013..0.015 rows=2 loops=1)
          Index Cond: (((parent_type)::text = 'Project'::text) AND (parent_id = '10821ae7-2867-46b5-a3ac-6b4cb709f7c0'::uuid))
          Filter: (tenant_id = '5189ea23-726f-4115-991d-959d09e3b858'::uuid)
  InitPlan 4 (returns $3)
    ->  Index Scan using index_elevation_sources_on_parent_type_and_parent_id on elevation_sources  (cost=0.08..4.09 rows=1 width=16) (actual time=0.010..0.010 rows=1 loops=1)
          Index Cond: (((parent_type)::text = 'Project'::text) AND (parent_id = '10821ae7-2867-46b5-a3ac-6b4cb709f7c0'::uuid))
          Filter: (tenant_id = '5189ea23-726f-4115-991d-959d09e3b858'::uuid)
  ->  Index Scan using installations_pkey on projects  (cost=0.09..4.09 rows=1 width=2403) (actual time=0.020..0.021 rows=1 loops=1)
        Index Cond: (id = '10821ae7-2867-46b5-a3ac-6b4cb709f7c0'::uuid)
        Filter: (tenant_id = '5189ea23-726f-4115-991d-959d09e3b858'::uuid)
  ->  Index Scan using index_load_profiles_on_project_id_and_tenant_id on load_profiles  (cost=0.11..4.12 rows=1 width=32) (actual time=0.011..0.011 rows=1 loops=1)
        Index Cond: (project_id = '10821ae7-2867-46b5-a3ac-6b4cb709f7c0'::uuid)
Planning time: 0.576 ms
Execution time: 0.167 ms

1 Ответ

1 голос
/ 27 мая 2020

План выполнения использует параллельный запрос, только если где-то в плане есть узел Gather (который собирает результаты от параллельных рабочих процессов). Таким образом, эти узлы будут не выполняться параллельно.

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

...