From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Allowing parallel-safe initplans |
Date: | 2023-04-12 18:06:05 |
Message-ID: | CA+TgmoaJEcfjM6weM-SQcZyjxk2RpBrc0ECNeP7rOGMomo-pdA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 12, 2023 at 12:44 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pursuant to the discussion at [1], here's a patch that removes our
> old restriction that a plan node having initPlans can't be marked
> parallel-safe (dating to commit ab77a5a45). That was really a special
> case of the fact that we couldn't transmit subplans to parallel
> workers at all. We fixed that in commit 5e6d8d2bb and follow-ons,
> but this case never got addressed.
Nice.
> Along the way, this also takes care of some sloppiness about updating
> path costs to match when we move initplans from one place to another
> during createplan.c and setrefs.c. Since all the planning decisions are
> already made by that point, this is just cosmetic; but it seems good
> to keep EXPLAIN output consistent with where the initplans are.
OK. It would be nicer if we had a more principled approach here, but
that's a job for another day.
> There's only one existing test case that visibly changes plan with
> these changes. The new plan is clearly saner-looking than before,
> and testing with some data loaded into the table confirms that it
> is faster. I'm not sure if it's worth devising more test cases.
It seems like it would be nice to see one or two additional scenarios
where these changes bring a benefit, with different kinds of plan
shapes.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-04-12 18:08:22 | Re: [PATCH] Allow Postgres to pick an unused port to listen |
Previous Message | Tom Lane | 2023-04-12 17:56:18 | Re: [PATCH] Allow Postgres to pick an unused port to listen |