Re: [HACKERS] Parallel Hash take II
От | Thomas Munro |
---|---|
Тема | Re: [HACKERS] Parallel Hash take II |
Дата | |
Msg-id | CAEepm=067qzQOvjSpAmMRXmXBgxTRmZX1hObUsi=_SRzepfqsw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Parallel Hash take II (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Parallel Hash take II
|
Список | pgsql-hackers |
On Sat, Sep 2, 2017 at 10:45 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Sep 1, 2017 at 6:32 PM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >> On Sat, Sep 2, 2017 at 5:13 AM, Robert Haas <robertmhaas@gmail.com> wrote: >>> On Thu, Aug 31, 2017 at 8:53 AM, Thomas Munro >>> <thomas.munro@enterprisedb.com> wrote: >>>> Check out ExecReScanGather(): it shuts down and waits for all workers >>>> to complete, which makes the assumptions in ExecReScanHashJoin() true. >>>> If a node below Gather but above Hash Join could initiate a rescan >>>> then the assumptions would not hold. I am not sure what it would mean >>>> though and we don't generate any such plans today to my knowledge. It >>>> doesn't seem to make sense for the inner side of Nested Loop to be >>>> partial. Have I missed something here? >>> >>> I bet this could happen, although recent commits have demonstrated >>> that my knowledge of how PostgreSQL handles rescans is less than >>> compendious. Suppose there's a Nested Loop below the Gather and above >>> the Hash Join, implementing a join condition that can't give rise to a >>> parameterized path, like a.x + b.x = 0. >> >> Hmm. I still don't see how that could produce a rescan of a partial >> path without an intervening Gather, and I would really like to get to >> the bottom of this. > > I'm thinking about something like this: > > Gather > -> Nested Loop > -> Parallel Seq Scan > -> Hash Join > -> Seq Scan > -> Parallel Hash > -> Parallel Seq Scan > > The hash join has to be rescanned for every iteration of the nested loop. I think you mean: Gather-> Nested Loop -> Parallel Seq Scan -> Parallel Hash Join -> Parallel Seq Scan -> Parallel Hash -> ParallelSeq Scan ... but we can't make plans like that and they would produce nonsense output. The Nested Loop's inner plan is partial, but consider_parallel_nestloop only makes plans with parallel-safe but non-partial ("complete") inner paths. /** consider_parallel_nestloop* Try to build partial paths for a joinrel by joining a partial path for the* outer relation to a complete path for the inner relation.* -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: