| From: | Ants Aasma <ants(at)cybertec(dot)at> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alastair Turner <minion(at)decodable(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Parallel copy |
| Date: | 2020-02-18 07:13:45 |
| Message-ID: | CANwKhkMH8nsjwz-gHdUbYRe-cTvhTS5ESBkk7+NpqWSCUpR9Rg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 18 Feb 2020 at 04:40, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> +1. That sort of two-queue scheme is exactly how I sketched out a
> multi-consumer queue for a hypothetical Parallel Scatter node. It
> probably gets a bit trickier when the payload has to be broken up into
> fragments to wrap around the "data" buffer N times.
At least for copy it should be easy enough - it already has to handle reading
data block by block. If worker updates its position while doing so the reader
can wrap around the data buffer.
There will be no parallelism while one worker is buffering up a line larger
than the data buffer, but that doesn't seem like a major issue. Once the line is
buffered and begins inserting next worker can start buffering the next tuple.
Regards,
Ants Aasma
| From | Date | Subject | |
|---|---|---|---|
| Next Message | sailor | 2020-02-18 07:23:46 | Re: BUG #16147: postgresql 12.1 (from homebrew) - pg_restore -h localhost --jobs=2 crashes |
| Previous Message | Kyotaro Horiguchi | 2020-02-18 07:05:00 | False failure during repeated windows build. |