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

Hi,

On 2021-03-23 16:04:59 -0400, Robert Haas wrote:
> It would be easy enough to set a flag in the relcache whose value is
> computed the first time we need it and is then consulted every time
> after that, and you just invalidate it based on sinval messages. But,
> if you go with that design, you've got a big problem: now an insert
> has to lock all the tables in the partitioning hierarchy to decide
> whether it can run in parallel or not, and we do not want that. We
> want to be able to just lock the partitions we need, so really, we
> want to be able to test for parallel-safety without requiring a
> relation lock, or only requiring it on the partitioned table itself
> and not all the partitions.

That seems like an argument for a pg_class attribute about parallel
safety of the current relation *and* its children. It'd definitely mean
recursing higher in the partition tree during DDL if the action on a
child partition causes the safety to flip.


> But if I had thought about it and had not come up with anything better
> than what you committed here, I would have committed nothing, and I
> think that's what you should have done, too.

I agree with that.


> Just to take one example, consider the code that forces a transaction
> ID assignment prior to the operation. You *could* have solved this
> problem by introducing new machinery to make it safe to assign an XID
> in parallel mode. Then, we'd have a fundamental new capability that we
> currently lack. Instead, you just force-assigned an XID before
> entering parallel mode. That's not building any new capability; that's
> just hacking around the lack of a capability to make something work,
> while ignoring the disadvantages of doing it that way, namely that
> sometimes an XID will be assigned for no purpose.

Although this specific hack doesn't seem too terrible to me. If you
execute a parallel insert the likelihood to end up not needing an xid is
pretty low. Implementing it concurrently does seem like it'd end up
needing another lwlock nested around xid assignment, or some more
complicated scheme with already holding XidGenLock or retries. But maybe
I'm missing an easy solution here.

Greetings,

Andres Freund