Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>, Tender Wang <tndrwang(at)gmail(dot)com>
Cc: Tomasz Rybak <tomasz(dot)rybak(at)post(dot)pl>, pgsql-hackers(at)lists(dot)postgresql(dot)org, robertmhaas(at)gmail(dot)com, David Rowley <dgrowleyml(at)gmail(dot)com>, "Fujii(dot)Yuki(at)df(dot)MitsubishiElectric(dot)co(dot)jp" <Fujii(dot)Yuki(at)df(dot)mitsubishielectric(dot)co(dot)jp>
Subject: Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Date: 2024-07-18 08:00:00
Message-ID: 7c09a439-e48d-5460-cfa0-a371b1a57066@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Richard,

12.07.2024 05:29, Richard Guo wrote:
> On Sat, Jul 6, 2024 at 5:32 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>> Here is a new rebase.
>>
>> I'm planning to push it next week, barring any objections.
> Pushed.

Please look at a recent buildfarm failure [1], which shows some
instability of that test addition:
 -- the joinrel is not parallel-safe due to the OFFSET clause in the subquery
 explain (costs off)
     select * from tenk1 t1, (select * from tenk2 t2 offset 0) t2 where t1.two > t2.two;
-                QUERY PLAN
--------------------------------------------
+                   QUERY PLAN
+-------------------------------------------------
  Nested Loop
    Join Filter: (t1.two > t2.two)
-   ->  Gather
-         Workers Planned: 4
-         ->  Parallel Seq Scan on tenk1 t1
+   ->  Seq Scan on tenk2 t2
    ->  Materialize
-         ->  Seq Scan on tenk2 t2
+         ->  Gather
+               Workers Planned: 4
+               ->  Parallel Seq Scan on tenk1 t1
 (7 rows)

I've managed to reproduce this plan change when running
multiple 027_stream_regress.pl instances simultaneously, with
parallel_schedule reduced to:
test: test_setup
test: create_misc
test: create_index
test: sanity_check
test: select_parallel

I've added the following to the test and got two verbose plans for
comparison (see the attachment).
 -- the joinrel is not parallel-safe due to the OFFSET clause in the subquery
 explain (costs off)
     select * from tenk1 t1, (select * from tenk2 t2 offset 0) t2 where t1.two > t2.two;
+\o plan.txt
+explain (verbose)
+    select * from tenk1 t1, (select * from tenk2 t2 offset 0) t2 where t1.two > t2.two;
+\o
 alter table tenk2 reset (parallel_workers);

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tamandua&dt=2024-07-17%2017%3A12%3A53

Best regards,
Alexander

Attachment Content-Type Size
plan.expected.txt text/plain 2.3 KB
plan.unexpected.txt text/plain 2.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2024-07-18 08:05:34 Re: Built-in CTYPE provider
Previous Message Daniel Gustafsson 2024-07-18 07:57:23 Re: optimizing pg_upgrade's once-in-each-database steps