0
votes

I'm trying to understand how Postgres works. After reading this, https://www.postgresql.org/message-id/4572.1280671706%40sss.pgh.pa.us These subqueries are subselects because they don't reference anything in the outer query right? So if they're independent, does that mean these are naturally run concurrently/parallel?

I was thinking these could be run in parallel with workers but it sounds like only one individual query may be run in parallel? As in, it would break apart a sequential scan or index scan with parallel workers?

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 Answers

1
votes

An execution plan uses parallel query only if there is a Gather node somewhere in the plan (which collects the results from parallel workers). So these nodes will not be executed in parallel.

There is no support in PostgreSQL yet for parallelizing such tasks, and it is indeed unlikely that there ever will be, since all parallel workers may need each of these results.