From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-committers <pgsql-committers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Add parallel-aware hash joins. |
Date: | 2017-12-21 12:48:59 |
Message-ID: | CAEepm=3eS6ra8oBCYsYYjPNsPqb2R_TaGQK8SGRFq_7gbP8RUg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Thu, Dec 21, 2017 at 10:55 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Thomas, I wonder if the problem is that PHJ_GROW_BATCHES_ELECTING
> updates, via ExecParallelHashJoinSetUpBatches(), HashJoinTable->nbatch,
> while other backends also access ->nbatch in
> ExecParallelHashCloseBatchAccessors(). Both happens after waiting for
> the WAIT_EVENT_HASH_GROW_BATCHES_ELECTING phase.
>
> That'd lead to ExecParallelHashCloseBatchAccessors() likely not finish
> writing all batches (because nbatch < nbatch_old), which seems like it'd
> explain this?
I don't think that's quite it, because it should never have set
'writing' for any batch number >= nbatch.
It's late here, but I'll take this up tomorrow and either find a fix
or figure out how to avoid antisocial noise levels on the build farm
in the meantime.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-12-21 14:25:03 | pgsql: Cancel CV sleep during subtransaction abort. |
Previous Message | Thomas Munro | 2017-12-21 11:46:09 | Re: condition variable cleanup and subtransactions |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2017-12-21 12:56:37 | Re: [HACKERS] Runtime Partition Pruning |
Previous Message | Fabien COELHO | 2017-12-21 12:44:59 | Re: General purpose hashing func in pgbench |