From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Ants Aasma <ants(at)cybertec(dot)at>, Alastair Turner <minion(at)decodable(dot)me>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Parallel copy |
Date: | 2020-02-18 15:11:49 |
Message-ID: | 20200218151148.GL24870@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)cybertec(dot)at> wrote:
> >
> > On Tue, 18 Feb 2020 at 12:20, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2020-02-18 15:13:50 | Re: Marking some contrib modules as trusted extensions |
Previous Message | Ants Aasma | 2020-02-18 14:38:13 | Re: Parallel copy |