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
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 |
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 |