Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <akapila(at)postgresql(dot)org>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
Date: 2021-03-26 03:59:44
Message-ID: CAA4eK1L7YcGcMdWB3Jh+YU_t+WftWuwr-YVONj_r77O5dZUNTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Thu, Mar 25, 2021 at 11:45 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Mar 25, 2021 at 5:08 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > Wouldn't we need to invalidate the hash entries as soon as something
> > parallel-unsafe is associated with them?
>
> Yes.
>
> > If so, how is this better
> > than setting a flag in relcache?
>
> You can't legally access a flag in the relcache without taking a
> relation lock.
>

But won't some form of lock is required for each rel entry in the hash
table as well for the same duration as is required for rel? Because
otherwise, while we are processing the statement or other relations in
the query, something parallel-unsafe could be attached to that
corresponding rel entry in the hash table. And, I feel probably some
concurrency bottleneck might happen because DDL/DML needs to access
this table at the same time.

--
With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Amit Kapila 2021-03-26 05:37:05 Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
Previous Message Robert Haas 2021-03-26 00:06:40 pgsql: Fix interaction of TOAST compression with expression indexes.