Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
От | Amit Kapila |
---|---|
Тема | Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode |
Дата | |
Msg-id | CAA4eK1J2ysWDnjQHLL-=5R7Td2d7MhqZHyXwiNbbqdgu4KqvLw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
|
Список | pgsql-committers |
On Wed, Mar 24, 2021 at 6:18 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Wed, Mar 24, 2021 at 12:48 AM Andres Freund <andres@anarazel.de> wrote: > > > 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. > > I don't think you need to do anything that is known outside the group > of processes involved in the parallel query. I think you just need to > make sure that only one of them is trying to acquire an XID at a time, > and that all the others find out about it. I haven't thought too hard > about the timing: if one process acquires an XID for the transaction, > is it OK if the others do an arbitrary amount of work before they > realize that this has happened? > A naive question about this scheme: What if the worker that acquires the XID writes some row and another worker reads that row before it gets to see the XID information? I think it won't treat such a row is written by its own transaction. Won't such a scheme lead to different behavior than serial inserts or where we have acquired XID before starting parallel-operation? -- With Regards, Amit Kapila.
В списке pgsql-committers по дате отправления: