Re: Parallel copy
От | Amit Kapila |
---|---|
Тема | Re: Parallel copy |
Дата | |
Msg-id | CAA4eK1JtPWKGm4phNF44=D8mkjBNe5Tbx9bo0TVeYEjreZnMWA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel copy (David Fetter <david@fetter.org>) |
Список | pgsql-hackers |
On Tue, Feb 18, 2020 at 8:41 PM David Fetter <david@fetter.org> wrote: > > On Tue, Feb 18, 2020 at 06:51:29PM +0530, Amit Kapila wrote: > > On Tue, Feb 18, 2020 at 5:59 PM Ants Aasma <ants@cybertec.at> wrote: > > > > > > On Tue, 18 Feb 2020 at 12:20, Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > This is something similar to what I had also in mind for this idea. I > > > > had thought of handing over complete chunk (64K or whatever we > > > > decide). The one thing that slightly bothers me is that we will add > > > > some additional overhead of copying to and from shared memory which > > > > was earlier from local process memory. And, the tokenization (finding > > > > line boundaries) would be serial. I think that tokenization should be > > > > a small part of the overall work we do during the copy operation, but > > > > will do some measurements to ascertain the same. > > > > > > I don't think any extra copying is needed. > > > > I am talking about access to shared memory instead of the process > > local memory. I understand that an extra copy won't be required. > > Isn't accessing shared memory from different pieces of execution what > threads were designed to do? > Sorry, but I don't understand what you mean by the above? We are going to use background workers (which are processes) for parallel workers. In general, it might not make a big difference in accessing shared memory as compared to local memory especially because the cost of other stuff in the copy is relatively higher. But still, it is a point to consider. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: