| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| 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-24 00:48:54 |
| Message-ID: | CA+Tgmob5-rekf=Ct=_Q+YA3_kJ0evHenxA0cdr-5m5k8Qt77Cg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 18, 2020 at 6:51 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> I am talking about access to shared memory instead of the process
> local memory. I understand that an extra copy won't be required.
You make it sound like there is some performance penalty for accessing
shared memory, but I don't think that's true. It's true that
*contended* access to shared memory can be slower, because if multiple
processes are trying to access the same memory, and especially if
multiple processes are trying to write the same memory, then the cache
lines have to be shared and that has a cost. However, I don't think
that would create any noticeable effect in this case. First, there's
presumably only one writer process. Second, you wouldn't normally have
multiple readers working on the same part of the data at the same
time.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2020-02-24 01:09:51 | Re: Parallel copy |
| Previous Message | Dagfinn Ilmari Mannsåker | 2020-02-24 00:31:59 | Re: Fixing parallel make of libpq |