Re: pgsql: Support Parallel Append plan nodes.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, amul sul <sulamul(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Support Parallel Append plan nodes.
Date: 2017-12-07 18:45:29
Message-ID: CA+TgmoarQFvpztuNH=VLNcs9gV1Wapyx_OEHMtmQT1cgOnBG5Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Thu, Dec 7, 2017 at 6:01 AM, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> wrote:
> I have not managed to make the regression test cases execute the above
> not-covered case. I could do that with my local test that I have, but
> that test has lots of data, so it is slow, and not suitable for
> regression. In select_parallel.sql, by the time a worker w1 gets into
> the function choose_next_subplan_for_worker(), an earlier worker w2
> must have already wrapped around the pa_next_plan at place_2, so this
> worker doesn't get a chance to hit place_1. It's a timing issue. I
> will see if I can solve this.

Well, it seems to me that just running the test case with
parallel_leader_participation = off might be good enough. It would
hit a decent chunk of this logic, and that's better than what we have
today. If we're determined to hit the wraparound case the way to do
it is probably to make the first child of the append something that
takes a long time to execute and the second one something quick. But,
as you say, it's hard to do such things in the regression tests
without making them slow, and I have observed Tom to dislike things
that make the regression tests slow.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2017-12-07 20:17:06 Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Previous Message Robert Haas 2017-12-07 16:17:55 Re: pgsql: When VACUUM or ANALYZE skips a concurrently dropped table, log i

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-12-07 18:49:37 Re: Logical replication without a Primary Key
Previous Message Alvaro Herrera 2017-12-07 18:37:10 Re: Speeding up pg_upgrade