| From: | Christopher Browne <cbbrowne(at)gmail(dot)com> |
|---|---|
| To: | srkrishna1(at)aol(dot)com |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, laurenz(dot)albe(at)cybertec(dot)at, Rob Sargent <robjsargent(at)gmail(dot)com>, PostgreSQL Mailing Lists <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: COPY threads |
| Date: | 2018-10-10 20:32:07 |
| Message-ID: | CAFNqd5UMtCNiHsMLkirywcZC=QOE=ThEy1ABn6-+rVC5j73g3Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Wed, 10 Oct 2018 at 16:22, Ravi Krishna <srkrishna1(at)aol(dot)com> wrote:
> You obviously are referring to multiple connections running COPY on different tables, right? Like what pg_restore does with -j option.
> Doesn't copy take an exclusive lock on the table which makes it incompatible with parallelization.
No, why would that seem to be the case? If it did so, then you could
not run pg_dump to dump data while regular activity was going on.
That's decidedly not the case.
The challenge in parallelizing a dump via COPY TO is in ensuring that
the multiple requests are attached to the same serializable
transaction. There's a function now that allows multiple connections
to attach to the same transaction context, I believe... Also, there's
the challenge in actually splitting the data, so that both requests
are dumping different data; that might be fairly expensive whether
with or without indices.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ravi Krishna | 2018-10-10 21:02:59 | Re: COPY threads |
| Previous Message | Ravi Krishna | 2018-10-10 20:21:54 | Re: COPY threads |